Re: [IndexedDB] Reason for aborting transactions

On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow <> wrote:
> On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking <> wrote:
>> On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow <> 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
>> 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 UTC