Re: [File API] Issue 182 about OperationNotAllowed

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.

Honestly, implementations are not consistent with respect to what they 
throw today with respect to FileException and read-affiliated 
exceptions, so if it helps get us some consistency by channeling things 
through DOM4 (and WebIDL), I'm okay with it, short term pain of changing 
the spec. notwithstanding.
>
> That means that in the places where we throw
> OperationNotAllowedException we should throw a DOMException with
> .name="InvalidStateError".

OK.
>
> For SECURITY_ERR we'll want to use DOMException with .name="SecurityError"

OK.
>
> For ABORT_ERR we'll want to use DOMException with .name="AbortError"

We don't actually throw an ABORT_ERR, so one thing that's attractive 
about making this change is that we'll eliminate redundant codes in 
objects we don't actually use.

>
> 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?

> For ENCODING_ERR, I think we'll want to mint a new error. DOMException
> with .name="CharsetEncodingError" maybe?

OK (same question).

> 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.

(Commentary from Anne welcome).

-- A*

Received on Monday, 3 October 2011 22:35:35 UTC