Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 9:04 PM, ben turner <bent.mozilla@gmail.com> wrote:

> > (It's somewhat frustrating when they come back localized, but bearable.)
>
> Sounds like what you really want is more specific error codes, not
> really messages, right?
>

Not always:

- 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.
- 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.

Error codes are useful when there are meaningful ways for a script to
respond to a particular type of failure, but there's not much you can do in
response to EDQUOT beyond displaying and/or reporting the error--the same is
probably true for most implementation-specific database "internal errors"
and so on.

-- 
Glenn Maynard