- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 3 Oct 2011 13:59:36 -0700
- To: arun@mozilla.com, Anne van Kesteren <annevk@opera.com>
- Cc: 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 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. That means that in the places where we throw OperationNotAllowedException we should throw a DOMException with .name="InvalidStateError". For SECURITY_ERR we'll want to use DOMException with .name="SecurityError" For ABORT_ERR we'll want to use DOMException with .name="AbortError" For NOT_READABLE_ERR I think we'll want to mint a new error. Something like DOMException with .name="IOError" or some such? For ENCODING_ERR, I think we'll want to mint a new error. DOMException with .name="CharsetEncodingError" maybe? In the cases where we reuse existing errors, the .code should be set to the code that the DOM4 spec defines. But I think if we use the correct vocabulary, the DOM4 spec will take care of that. cc'ing Anne who helped out with this for IndexedDB recently. / Jonas
Received on Monday, 3 October 2011 21:00:33 UTC