Re: [File API] Issue 182 about OperationNotAllowed

On 10/4/11 2:54 AM, Anne van Kesteren wrote:
> On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking <jonas@sicking.cc> 
> wrote:
>> 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 could certainly introduce a DOMError interface with a name and a 
> message attribute. For the APIs that want to provide the same 
> information asynchronous as they do synchronous through exceptions 
> that makes sense. Would that work?

Works for me :-)  Happy to work with you to introduce DOMError in DOM4; 
seems pretty straightforward and as soon as it is in, I'll refer to it.

OK, it's time to bid a fond farewell to FileException and FileError if 
that's the way we're doing exceptions from this day forward.

>
>
>>> 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.
>
> The idea I had was that everyone can introduce new strings. After all, 
> as far as normative statements in a specification go, you need nothing 
> more than this line:
>
> # Throw a "SyntaxError" exception
>
> On top of that my plan was that whenever a specification author 
> introduces a string there that is not yet in DOM4 they send a request 
> for it to be included and one of the DOM4 editors will add the 
> exception and a brief description to the overview table. Having it in 
> the overview table will help other editors choosing the appropriate 
> string. Apart from making sure certain strings get their legacy code 
> value assigned (already in the table) the table would be completely 
> non-normative however and no specification introducing strings not yet 
> in the table is blocked by it updating. It's just an overview.
>
>
OK, this works for me.

-- A*

Received on Tuesday, 4 October 2011 15:32:34 UTC