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

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?

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.

Israel

Received on Tuesday, 7 June 2011 02:20:12 UTC