On Tue, Apr 26, 2011 at 10:05 PM, Jonas Sicking wrote: > On Tue, Apr 26, 2011 at 8:23 PM, Cameron McCormack <[email protected]> > 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
