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

Re: [indexeddb] New WebIDL Exception Model for IndexedDB

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 26 Sep 2011 11:35:30 +0200
To: "public-webapps@w3.org" <public-webapps@w3.org>, "Israel Hilerio" <israelh@microsoft.com>
Message-ID: <op.v2esxgwz64w2qv@annevk-macbookpro.local>
On Mon, 26 Sep 2011 09:31:36 +0200, Anne van Kesteren <annevk@opera.com>  
> On Fri, 23 Sep 2011 00:52:39 +0200, Israel Hilerio  
> <israelh@microsoft.com> wrote:
>> This is our understanding on how the spec needs to change to support  
>> the new WebIDL exception handling model.  We would start by removing  
>> all of the constants from IDBDatabaseException.  After that, the only  
>> thing left would be message.  Do we still need to have this class  
>> definition?  It seems we can remove it.
>> In either case, we would have to continue by defining a set of  
>> exception types and code mappings. Each exception type will have a code  
>> value of 0.
>> The mapping will look like this:
>> UnknownError(0)
>> NonTransientError(0)
>> NotFoundError(0)
>> ConstraintError(0)
>> DataError(0)
>> NotAllowedError(0)
>> TransactionInactiveError(0)
>> AbortError(0)
>> ReadOnlyError(0)
>> TimeoutError(0)
>> QuotaError(0)
>> VersionError(0)
>> If we believe the message attribute is still relevant, then we would  
>> define the IDBDatabaseException class like this:
>> exception IDBDatabaseException: DOMException {
>>     DOMString      message;
>> };
>> Using this approach, IDBDatabaseException will inherit the name and  
>> code properties from DOMException.
>> Is this what you had in mind?
> The new approach is outlined here:
>    http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c14
> I should probably update DOM4 with some easy to use language, including  
> how this maps to the code member.

I've done that now.


If that is correct I would expect Indexed Database API to say e.g.

"throw a VersionError exception" in its prose.

We should probably keep these exceptions central somewhere so we do not  
mint similar exceptions twice. E.g. QuotaError looks like it could be the  
same as the existing QuoteExceededError.

The table in DOM4 could be that central place I suppose as other than the  
code numbers it is largely non-normative so we could update it as  
editorial changes whenever we want.

What do people think?

Anne van Kesteren
Received on Monday, 26 September 2011 09:36:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:24 UTC