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
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, <bugzilla@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.null@w3.org
>        ReportedBy: jorlow@chromium.org
>         QAContact: member-webapi-cvs@w3.org
>                CC: mike@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.
>
>