W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Jeremy Orlow <jorlow@chromium.org>
Date: Fri, 10 Dec 2010 18:09:06 +0000
Message-ID: <AANLkTinEfYUtc70V0Pg_K-XbmHQWdEFR01kL5+6qNW5E@mail.gmail.com>
To: Shawn Wilsher <sdwilsh@mozilla.com>
Cc: public-webapps@w3.org
On Fri, Dec 10, 2010 at 6:01 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:

> On 12/10/2010 5:03 AM, Jeremy Orlow wrote:
>
>> 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.)
>>
> Would a CONSTRAINT_ERR make more sense?


This error doesn't really apply to internal implementation issues in my
mind.  In addition, some of the places we can hit this also return
CONSTRAINT_ERRs for other reasons.

 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)?
>>
> I think NOT_FOUND_ERR makes sense there.


Sounds good to me.


>  TRANSIENT_ERR doesn't seem to be used anywhere in the spec.  Should it be
>> removed?
>>
> I can't think of anything that we'd actually want to use it for.
>
>
>  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 think it is fine to just renumber.  If anyone is relying on the numbers
> being a certain thing now, I think it's probably best just to have a clean
> break instead of sometimes being right still.
>
> Cheers,
>
> Shawn
>
>
Received on Friday, 10 December 2010 18:09:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT