Re: [Indexeddb} Bug # 9653 - nullable violations on parameters

On Mon, Jun 6, 2011 at 7:19 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> On Tue, Apr 26, 2011 at 10:05 PM, Jonas Sicking wrote:
>> On Tue, Apr 26, 2011 at 8:23 PM, Cameron McCormack <cam@mcc.id.au>
>> wrote:
>> > Jonas Sicking:
>> >> However it appears that that extended attribute is not present in
>> >> newer versions of the WebIDL spec. Cameron, is this something that is
>> >> planned to be brought back? It seems like a useful feature to avoid
>> >> having to define in prose this rather common requirement. We should
>> >> also define which exception should be thrown if such a [NoNull]
>> >> requirement was violated.
>> >
>> > I plan to make object types non-nullable by default, and to allow null
>> > you would write "MyInterface?".
>> >
>> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640.
>> >
>> > I will most likely make passing in null for a non-nullable object type
>> > result in a TypeError being thrown.
>>
>> Excellent! I think that should mean that no changes are needed to the
>> IndexedDB spec at all. I can't think of any instances where we use specific
>> interface names while still accepting null values.
>>
>> / Jonas
>>
>> / Jonas
>
> Based on this conversation, we agreed that we wanted to throw a TypeError when a non-nullable parameter was passed a null argument.  This implies to me, for example, that if we were to pass a null value for the key parameter of IDBObjectStore.put we will throw a TypeError (i.e. InvalidArgument).  We're assuming this Exception takes precedence over any IDB Exceptions (i.e. DATA_ERR).
>
> This seems like a common pattern we want to enforce everywhere, throwing a TypeError before any type of IDBError when passing null to non-nullable arguments.  Do you agree?

Yes.

> The reason I'm asking is that we found FireFox does this a little different.  They are throwing a DATA_ERR when passing null as a key value.  I just want to make sure we're on the same page.

I expect that we'll end up having to change lots of exceptions in the
Firefox implementation.

/ Jonas

Received on Tuesday, 7 June 2011 02:55:13 UTC