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

Re: [indexeddb] New WebIDL Exception Model for IndexedDB

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 24 Oct 2011 17:31:33 -0700
Message-ID: <CA+c2ei8y18AH-vL++BPimDzokVATg-1p=czAymcK6yJHf_E5+g@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: public-webapps@w3.org
On Mon, Oct 24, 2011 at 4:23 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> Replying late here, but:
>
> On 29/09/11 12:03 AM, Jonas Sicking wrote:
>>
>> From my understanding of the WebIDL spec, the idea is that
>> specifications like IndexedDB should throw exceptions which use the
>> DOMExceptions interface. The various errors would use different string
>> values for .name which would replace the current codes that we have
>> now. However, if existing ECMAScript errors can be used, we should use
>> those.
>>
>> Cc'ing Cameron so that he can confirm that this is a correct
>> understanding.
>
> That's not actually what the changes allow.  The built-in Error types in
> ECMAScript are not available at the IDL level.  But I think that it would be
> better if they are.  I can lift them up to the IDL level, and define what it
> means to "throw a TypeError" in other languages.

So I actually do think that we want to explicitly throw a TypeError
from at least one place in IndexedDB. Which is if you pass a illegal
value to a function which takes an enumerated value. For example
IDBDatabase.transaction has a second argument which indicates readonly
or read/write (we might add other types in the future which is why
it's not a bool). Here we'll want to throw a TypeError if someone
passes the wrong value.

/ Jonas
Received on Tuesday, 25 October 2011 00:32:34 GMT

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