I was confused re not overlapping with other exception codes. As long as we don't have overlap within this particular exception type, we're OK.
I noticed that QUOTA_ERR is commented out. I can't remember when or why and the blame history is a bit mangled. Does anyone else? In Chromium we currently use UNKNOWN_ERR for whenever we have issues writing stuff to disk. We could probably tease quota related issues out into their own error. And/or we should probably create or find a good existing error for such uses. Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) We also use UNKNOWN_ERR for when things are not yet implemented. Any concerns? What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I intend to tackle this early next week unless there are major areas of contention. J On Mon, Nov 22, 2010 at 12:43 PM, <bugzi...@jessica.w3.org> wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11375 > > Summary: [IndexedDB] Error codes need to be assigned new > numbers > Product: WebAppsWG > Version: unspecified > Platform: PC > OS/Version: All > Status: NEW > Severity: normal > Priority: P2 > Component: Indexed Database API > AssignedTo: dave.n...@w3.org > ReportedBy: jor...@chromium.org > QAContact: member-webapi-...@w3.org > CC: m...@w3.org, public-webapps@w3.org > > > The error codes specced in IDBDatabaseException's interface need to be > redone. > They currently overlap with existing exception error codes and use 0 which > we've avoided using in the past [0]. In addition, the codes are > non-contiguous > which also seems to be non-standard. We should re-map the exception > numbers > into something contiguous that doesn't overlap with other exception codes. > > > [0] I'm not sure if 0 is actually specced to be reserved, but in practice > it > seems to be. And WebKit uses 0 internally to signal "no exception". > > -- > Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. > >
