Re: [File API] Issue 182 about OperationNotAllowed

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