Re: [IndexedDB] Reason for aborting transactions

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.

-Ben

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