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

Re: [IndexedDB] Reason for aborting transactions

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 8 Feb 2011 02:21:34 -0800
Message-ID: <AANLkTikRsFbTuNVGYegwrH-5wt-n3oPFZChzYLLQja=V@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Cameron McCormack <cam@mcc.id.au>, public-webapps WG <public-webapps@w3.org>
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 10:22:26 GMT

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