Re: [IndexedDB] Reason for aborting transactions

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?


> 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?  And maybe revisit in the future?

J