W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [File API] Issue 182 about OperationNotAllowed

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 04 Oct 2011 11:31:53 -0400
Message-ID: <4E8B26E9.6020606@mozilla.com>
To: Anne van Kesteren <annevk@opera.com>
CC: Jonas Sicking <jonas@sicking.cc>, Adrian Bateman <adrianba@microsoft.com>, Arthur Barstow <art.barstow@nokia.com>, Jonas Sicking <sicking@mozilla.com>, public-webapps <public-webapps@w3.org>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC