- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 3 Oct 2011 15:59:18 -0700
- To: arun@mozilla.com
- Cc: Anne van Kesteren <annevk@opera.com>, Adrian Bateman <adrianba@microsoft.com>, Arthur Barstow <art.barstow@nokia.com>, Jonas Sicking <sicking@mozilla.com>, public-webapps <public-webapps@w3.org>
On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan <arun@mozilla.com> wrote: > On 10/3/11 4:59 PM, Jonas Sicking wrote: >> >> On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan<arun@mozilla.com> >> wrote: >>> >>> On 9/30/11 9:46 PM, Adrian Bateman wrote: >>>> >>>> Hi Arun, >>>> >>>> Thanks for the follow-up - you beat me to it. We've been reviewing this >>>> in >>>> the context of the other specs and, as Israel outlined for IndexedDB, >>>> we're >>>> happy with the new WebIDL approach. >>>> >>>> I think we should go ahead and migrate the File API exceptions to this >>>> new >>>> model and use ISSUE-182 to drive that change. >>> >>> Adrian, >>> >>> That's great :) Just to clarify from a File API perspective, are you ok >>> with an OperationNotAllowed exception, *or* are you advocating reuse of >>> DOMException with OperationNotAllowed like how IndexedDB is doing? I'm >>> unclear whether I should change what is in the editor's draft now. >>> >>> A somewhat affiliated question is whether there should be a "message" >>> attribute in our FileException and OperationNotAllowed exceptions (and in >>> FileError). >> >> Here are my feelings: >> >> 1. Get rid of FileError/OperationNotAllowedException completely. All >> exceptions we throw should be DOMExceptions. >> 2. We should try to reuse as many exceptions as we can from the DOM4 spec. > > Eeep! :) This is a big-ish change, but I'm amenable to it, especially to > stay consistent with what IndexedDB is doing (and to be consistent with > HTML/XHR2, etc.). But to be clear, above you mean: > > 1. Get rid of FileException and OperationNotAllowedException completely, but > you probably do NOT mean get rid of FileError. We'll want to keep FileError > since it's an asynchronously handled error object in onerror, but we'll > reuse whatever we reuse from DOMException, if it makes sense to do so. Yup. I do wonder if we should introduce a DOMError class which can be reused in various cases which need APIs like this. IndexedDB could also use it and I seem to recall that HTML5 does too. >> For NOT_READABLE_ERR I think we'll want to mint a new error. Something >> like DOMException with .name="IOError" or some such? > > OK. So it's when we need new exception codes, names, and types that the > confusion with this model sets in. While we can add to DOMException in a > decentralized way, do the editors of DOM4 intend to add the new exceptions > to DOMException? I'll leave this one for Anne. I personally don't care where the new strings are defined. Anne seemed to prefer to do it in the DOM4 (aka DOM Core) spec, but I don't think we want to block on that happening. / Jonas
Received on Monday, 3 October 2011 23:00:19 UTC