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

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

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

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

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


On Mon, Nov 22, 2010 at 12:43 PM, <> wrote:

>           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:
>        ReportedBy:
>         QAContact:
>                CC:,
> 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:
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

Received on Friday, 10 December 2010 13:04:02 UTC