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

RE: [indexeddb] New WebIDL Exception Model for IndexedDB

From: Israel Hilerio <israelh@microsoft.com>
Date: Sat, 1 Oct 2011 00:56:55 +0000
To: Anne van Kesteren <annevk@opera.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3F4BE7C4@TK5EX14MBXC117.redmond.corp.microsoft.com>
On Friday, September 30, 2011 12:23 AM, Anne van Kesteren wrote:
> On Thu, 29 Sep 2011 23:54:50 +0200, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > Microsoft believes that the following text closer reflects the intent
> > on the WebIDL spec:
> > * Throws a DOMException of type " VersionError".
> > (vs. Throw a VersionError exception, which doesn’t accurately capture
> > the intent defined in the WebIDL spec)
> 
> 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".

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.

> 
> > As we mentioned before, we agree on the reuse of existing DOM level 4
> > Exceptions currently contained in the spec.  However, it is our stance
> > that feature specific exceptions should be defined in the spec that
> > they are used in.  With the new WebIDL model, it’s not necessary to
> “define”
> > the exceptions anywhere. Anyone can just state in their spec: "Throw a
> > DOMException of type FooBar" and that’s it.
> 
> Yes, but how do you prevent e.g. WrongVersionError from appearing next to
> VersionError if there is no central lookup? Do you expect people that mint
> new exceptions to look at all specifications that use exceptions? The
> exceptions defined in DOM4 are already not specific to DOM4, e.g.
> NetworkError is mostly for XMLHttpRequest at this point, as is TimeoutError.
> 

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

> 
> > This is the pattern we're looking to follow for IndexedDB.
> 
> 
> --
> Anne van Kesteren
> http://annevankesteren.nl/


Israel
Received on Saturday, 1 October 2011 00:57:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT