- From: ben turner <bent.mozilla@gmail.com>
- Date: Tue, 8 Feb 2011 08:07:50 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Jeremy Orlow <jorlow@chromium.org>, Cameron McCormack <cam@mcc.id.au>, public-webapps WG <public-webapps@w3.org>
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