- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 8 Feb 2011 02:21:34 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Cameron McCormack <cam@mcc.id.au>, public-webapps WG <public-webapps@w3.org>
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 10:22:26 UTC