This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9653 - How to handle nullable violations is not specified.
Summary: How to handle nullable violations is not specified.
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Nikunj Mehta
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2010-05-04 16:56 UTC by Shawn Wilsher :sdwilsh (Mozilla)
Modified: 2011-07-05 17:31 UTC (History)
5 users (show)

See Also:


Description Shawn Wilsher :sdwilsh (Mozilla) 2010-05-04 16:56:06 UTC
The spec doesn't say what the correct course of action is if a consumer passes null to something that is not null.
Comment 1 Jonas Sicking (Not reading bugmail) 2010-11-08 18:35:51 UTC
Is this still a problem. I've tried to be thorough in defining invalid values everywhere. The sync API is still not up-to-date, but that's a bigger problem that we should handle separately.
Comment 2 Jeremy Orlow 2010-12-10 12:23:06 UTC
Are you planning on working on this soon?  If not, maybe you should assign it to
Comment 3 Eliot Graff 2011-07-05 17:31:34 UTC
From mail [1]:

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).

I believe that this satisfies the request in this bug, so I am resolving it as fixed.