- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 7 Feb 2011 19:36:39 -0800
- To: Jeremy Orlow <jorlow@chromium.org>, Cameron McCormack <cam@mcc.id.au>
- Cc: public-webapps WG <public-webapps@w3.org>
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. 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. / Jonas
Received on Tuesday, 8 February 2011 03:37:32 UTC