W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

RE: [indexeddb] New WebIDL Exception Model for IndexedDB

From: Israel Hilerio <israelh@microsoft.com>
Date: Thu, 29 Sep 2011 21:54:50 +0000
To: "annevk@opera.com" <annevk@opera.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3F4BC315@TK5EX14MBXC117.redmond.corp.microsoft.com>
On Tuesday, September 27, 2011 1:11 AM, Anne van Kesteren wrote:
> On Tue, 27 Sep 2011 02:40:29 +0200, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > Like Cameron says in the link above and based on the WebIDL
> > description, it seems we want the IndexedDB text to say, for example:
> > Throws a DOMException of type " VersionError". (vs. Throw a
> > VersionError
> > exception)
> 
> He made a suggestion. I just simplified what you have to say to get the same
> effect, if you use the DOM4 terminology. If the decision is that all non-IDL
> exceptions are DOMException I think my approach is better.

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)

> > In addition, it seem that the names I outlined above match the
> > expected naming convention outlined in the link you specified.
> > However, we shouldn't redefine any types which are already included in
> > the DOM 4 exceptions section.  We should just use them and point to
> them.
> >
> > For IndexedDB, we will include the following database specific
> > exceptions in our spec:
> > UnknownError
> > NonTransientError
> > ConstraintError
> > DataError
> > NotAllowedError
> > TransactionInactiveError
> > ReadOnlyError
> > VersionError
> > All of these exceptions will have a code of 0.
> >
> > In addition, we would reuse the following types from the DOM 4
> > Exception
> > section:
> > NotFoundError
> > AbortError
> > TimeoutError
> > QuotaExceededError
> >
> > While I can see the benefits of having an all-encompassing list of
> > exceptions people can go to see the various types, it seems that this
> > could grow very large and we'll see may exceptions which are not
> > applicable to other technologies.  To that effect, we prefer all new
> > feature specific exceptions to be included in the spec they are used
> > instead of a centralized table.
> 
> I think that is the wrong approach. We have shared exception types
> throughout the web platform to date. That is, exceptions are generic already.
> It would be good I think if we not deviated from that and reuse exceptions.
> To do that specification writers need to be able to look up somewhere which
> exceptions are already defined and which are a match for what they are
> doing.

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.

This is the pattern we're looking to follow for IndexedDB.

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


Israel
Received on Thursday, 29 September 2011 21:55:20 GMT

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