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 c...@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
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
On Mon, Jun 6, 2011 at 7:19 PM, Israel Hilerio isra...@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 c...@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
RE: [Indexeddb} Bug # 9653 - nullable violations on parameters
On Tue, Apr 26, 2011 at 10:05 PM, Jonas Sicking wrote: 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 This implies the bug can be resolved, correct? Israel
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
On Mon, May 2, 2011 at 1:49 PM, Israel Hilerio isra...@microsoft.com wrote: On Tue, Apr 26, 2011 at 10:05 PM, Jonas Sicking wrote: 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 This implies the bug can be resolved, correct? Unless someone points out any specific functions in the API that needs clarification, I think we should close the bug yes. / Jonas
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
On Tue, Apr 26, 2011 at 6:57 PM, Israel Hilerio isra...@microsoft.com wrote: Did you come up with a conclusion on how to handle null violations: * Bug 9653 [1] - How to handle nullable violations is not specified. I looked for previous threads and couldn't find anything. It seems to me we should throw a NON_TRANSIENT_ERR when a developer uses a null value on a non-nullable parameter. What do you think? Which functions in particular are you referring to? I never really understood the relevant bug as it didn't mention which functions it's about. However in general I think we should reuse WebIDL as much as possible. It used to define a extended attribute [NoNull] which you could specify on an argument and would indicate that the function should throw if a null value was passed. This is useful for for example the second argument in the Node.insertBefore function. 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. / Jonas
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
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. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
On Tue, Apr 26, 2011 at 8:23 PM, Cameron McCormack c...@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
