Re: [File API] Issue 182 about OperationNotAllowed

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?


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


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 4 October 2011 06:55:40 UTC