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: Wed, 15 Dec 2010 00:16:09 +0000
Message-ID: <AANLkTimDaQhD3Fx74QwstUAqvtzhQzLQAaR-SKV4Jh+O@mail.gmail.com>
To: Pablo Castro <Pablo.Castro@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, Dec 15, 2010 at 12:08 AM, Pablo Castro

> From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org]
> 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.

I'll re-add it then.

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

Hopefully it won't be a big deal.  I think most browsers are a bit more fast
and loose with shipping half working things before anyone else has shipped
something rock solid (that people are using in production).  I expect that
our couple instances of this will go away pretty soon.

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

Shawn said NOT_FOUND_ERR.  NOT_ALLOWED_ERR seems slightly better to me.
 Shawn, what do you think?

>  >> TRANSIENT_ERR doesn't seem to be used anywhere in the spec.  Should it
> be removed?
> Sure.
> >> 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'm fine with that.
> -pc
Received on Wednesday, 15 December 2010 00:17:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:14 UTC