On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan <[email protected]> wrote: > On 10/3/11 4:59 PM, Jonas Sicking wrote: >> >> On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan<[email protected]> >> 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
