RE: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers

From: [] On Behalf Of Jeremy Orlow
Sent: Friday, December 10, 2010 5:03 AM

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

It sounds like a good idea to keep QUOTA_ERR separated from other general errors that come up when writing stuff to disk.

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

That sounds reasonable to me. 

>> We also use UNKNOWN_ERR for when things are not yet implemented.  Any concerns?

I don't think it's a big deal, but are we going to have a bunch of unimplemented stuff across browsers? If this becomes common, I wonder if we should have a separate error so calling code can choose to compensate or something.

>> 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'm fine with that.


Received on Wednesday, 15 December 2010 00:09:43 UTC