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

Re: [IndexedDB] Reason for aborting transactions

From: ben turner <bent.mozilla@gmail.com>
Date: Tue, 8 Feb 2011 08:07:50 -0800
Message-ID: <AANLkTinGNs2TUFKLesvcm2ZUO2LGmBMA4ENWT=CgTTO9@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Jeremy Orlow <jorlow@chromium.org>, Cameron McCormack <cam@mcc.id.au>, public-webapps WG <public-webapps@w3.org>
Why not just expand our list of error codes to have multiple ABORT_
variants for each situation, and then always fire the "abort" event
with a slightly different errorCode?

That seems far simpler IMO.


On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
>>> > We do that as well.
>>> > What's the best way to do it API wise?  Do we need to add an
>>> > IDBTransactionError object with error codes and such?
>>> I don't actually know. I can't think of a precedence. Usually you use
>>> different error codes for different errors, but here we want to
>>> distinguish a particular type of error (aborts) into several sub
>>> categories.
>> I don't see how that's any different than what we're doing with the onerror
>> error codes though?
> Hmm.. true.
>>> To make this more complicated, I actually think we're going to end up
>>> having to change a lot of error handling when things are all said and
>>> done. Error handling right now is sort of a mess since DOM exceptions
>>> are vastly different from JavaScript exceptions. Also DOM exceptions
>>> have a messy situation of error codes overlapping making it very easy
>>> to confuse a IDBDatabaseException with a DOMException with an
>>> overlapping error code.
>>> For details, see
>>> http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html
>>> So my gut feeling is that we'll have to revamp exceptions quite a bit
>>> before we unprefix our implementation. This is very unfortunate, but
>>> shouldn't be as big deal of a deal as many other changes as most of
>>> the time people don't have error handling code. Or at least not error
>>> handling code that differentiates the various errors.
>>> Unfortunately we can't make any changes to the spec here until WebIDL
>>> prescribes what the new exceptions should look like :(
>>> So to loop back to your original question, I think that the best way
>>> to expose the different types of aborts is by adding a .reason (or
>>> better named) property which returns a string or enum which describes
>>> the reason for the abort.
>> Could we just add .abortCode, .abortReason, and constants for each code to
>> IDBTransaction?
> Why both? How are they different. I'd just go with the former to align
> with error codes.
>> And maybe revisit in the future?
> Yes. I think we need to wait for webidl to solidify a bit here before
> we do anything.
> / Jonas
Received on Tuesday, 8 February 2011 16:08:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC