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

Re: [IndexedDB] Reason for aborting transactions

From: Jeremy Orlow <jorlow@chromium.org>
Date: Mon, 7 Feb 2011 20:05:46 -0800
Message-ID: <AANLkTi=e=9B07xknMdJwxcT-rLc5POHWywCZ1o3J2Q9F@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Cameron McCormack <cam@mcc.id.au>, public-webapps WG <public-webapps@w3.org>
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?

Received on Tuesday, 8 February 2011 04:06:38 UTC

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