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

Re: [indexeddb] New WebIDL Exception Model for IndexedDB

From: Anne van Kesteren <annevk@opera.com>
Date: Sat, 01 Oct 2011 08:15:27 +0200
To: "Israel Hilerio" <israelh@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <op.v2nsz1sx64w2qv@annevk-macbookpro.local>
On Sat, 01 Oct 2011 02:56:55 +0200, Israel Hilerio <israelh@microsoft.com>  
> On Friday, September 30, 2011 12:23 AM, Anne van Kesteren wrote:
>> Actually, given
>> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw
>> it does. Which is what I was trying to convey. HTML does this too now:
>> http://html5.org/r/6602
> The DOM 4 spec link you sent us is exactly the approach we’re following  
> but with a simpler language.  Instead of defining what it means to throw  
> a type as an exception (like you do on DOM 4), we’re following the  
> WebIDL spec to define the exception type in a simpler fashion.  Look at  
> the note contained in the WebIDL spec under IDL Exceptions where it says  
> there is no IDL syntax for declaring exception types:
> http://dev.w3.org/2006/webapi/WebIDL/#idl-exceptions
> We believe it is simpler and closer to the intent on the WebIDL spec to  
> say: Throws a DOMException of type " VersionError".

It's also wrong, since it does not say what code will be.

> Instead of having to explain what it means to throw a type as an  
> exception:
> To throw a “VersionError” exception, a user agent would construct a  
> DOMException exception whose type is " VersionError " and code exception  
> field value is 0, and actually throw that object as an exception.

It seems you misunderstood DOM4. All you need to say is:

# Throw a "VersionError" exception

That is it. The DOM4 definition of "throw" handles the details, such as  
setting message and code.

> This discussion shows that the review process can catch these types of  
> issues and reviewers like yourself can make us aware of exceptions we  
> should reuse.  Even if it didn’t, the worst case scenario is that a  
> developer would have similar Exceptions that have slightly different  
> types and names.  Each name or type should be meaningful enough for the  
> developer to allow them to disambiguate.  The main point is that we  
> don’t believe we should over engineer a solution to a problem that is  
> not pervasive at this point.
> We could even add a note to the DOM 4 spec that states, "We encourage  
> the reuse of these exceptions instead of defining new ones.  Only define  
> new ones if the current set of exceptions doesn’t meet your needs."

I guess I don't really see what you think the problem is with keeping a  
non-normative table in DOM4 (or elsewhere) listing the exceptions in use.

Anne van Kesteren
Received on Saturday, 1 October 2011 06:15:56 UTC

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