Re: [IndexedDB] Reason for aborting transactions

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.
>

Sorry, I meant .abortMessage instead of .abortReason.  This would be much
like normal error messages where we have a code that's standardized and easy
for scripts to understand and then the message portion which is easy for
humans to understand but more ad-hoc.


> > And maybe revisit in the future?
>
> Yes. I think we need to wait for webidl to solidify a bit here before
> we do anything.
>

I think we should put something in our spec in the mean time, but once
WebIDL solidifies then we can revisit and try to match what's decided there.


On Tue, Feb 8, 2011 at 8:07 AM, ben turner <bent.mozilla@gmail.com> wrote:

> 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.


If that is OK spec wise, I'm fine with it.  To be honest, hanging
ABORT_BLAHs off IDBDatabaseException seems a bit odd though.

J