Re: [File API] Issue 182 about OperationNotAllowed

On 10/3/11 6:59 PM, Jonas Sicking wrote:
> 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.

I'm happy with a DOMError class that can be reused, but I'd rather not 
block on it unless it can be done in short order.  It might live in 
HTML, although currently the onerror handler for script errors (if a 
Function) has three arguments and doesn't seem to need a dedicated error 
object.

Earlier, when I wanted to keep constants in sync with DOMException, 
there was some resistance.  If we maintain a FileError object, it may 
now actually make sense to replicate some of the constants from 
DOMException, since there is no longer a FileException.  Or, we can 
follow how HTML handles script errors (and forego a dedicated error object).

Cc'ing Hixie as well to comment on what HTML might need.
>
>> 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.

I don't think we should block on DOM4 either.

-- A*

Received on Monday, 3 October 2011 23:19:34 UTC