Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 6:39 PM, Glenn Maynard <glenn@zewt.org> wrote:
> 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.

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.

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

/ Jonas

Received on Thursday, 10 February 2011 02:47:34 UTC