W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [IndexedDB] Reason for aborting transactions

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 9 Feb 2011 21:39:48 -0500
Message-ID: <AANLkTikqmWNqV_y1u7rjq1Cpt3Tpv0R3Q6hsJg-YpcEV@mail.gmail.com>
To: ben turner <bent.mozilla@gmail.com>
Cc: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Cameron McCormack <cam@mcc.id.au>, public-webapps WG <public-webapps@w3.org>
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
Received on Thursday, 10 February 2011 02:40:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT