Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 9:46 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> > - Some errors are implementation-specific.  For example, if "internal
> error"
> > is caused by SQLite under the hood returning an unexpected error that the
> > browser can't recover from, the browser could include the SQLite error
> > message.  That's not something that should be specced specifically, but
> it
> > may be very helpful on the developer's side to knowing what went wrong on
> a
> > user's system to be able to follow up the problem.  Similarly, if a
> File-API
> > write fails due to EDQUOT because of the user's hard disk quota (not to
> be
> > confused with the browser's quota), receiving strerror(EDQUOT) as part of
> > the message would be very useful, but shouldn't be laid out as a specific
> > error code in the spec.
>
> Note that in both these cases the browser probably doesn't want to
> forward the message it gets from the OS or from SQLite directly to the
> webpage. Such a message can contain sensitive information such as
> usernames and filenames.
>

Right; it's the implementation's job to pay attention to where its messages
are coming from.  For example, you shouldn't blindly forward an error
message string from a database backend (which may include paths).  However,
returning a stringification of SQLITE_* constants or strerror(errno), seems
perfectly safe and very useful.

 > - Some errors contain other information that may not be
> > implementation-specific, but may not be worth codifying into the spec.
> For
> > example, it's not worth trying to encode an error message for every
> possible
> > Regex parsing failure.  Browsers may also give additional information
> that's
> > not useful to spec; for example, "17" in "open parentheses at pos 17 not
> > closed".  Javascript parsing failures might include the context of a
> > compilation error.
>
> This is more interesting, but I'm not sure that it applies to abort
> codes? The one case I can think of is unhandled errors which result in
> an abort. However in that case we should have already fired
> window.onerror with the information you're talking about.
>

I was looking over the spec on success and error events some more while
considering this, and I'm deeply confused: 3.2.2 describes the success and
error events being fired at the Window ("at each Window object") rather then
at the request, which seems bizarre.  I feel like this is an embarrassing
spec-novice question, but could someone clue me in on what's happening here?

-- 
Glenn Maynard