W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 23 Jan 2012 20:21:35 -0800
Message-ID: <CA+c2ei9urq1k9yoACb+kzUnZETC-fRAL-dvq2VPtDE85p7pCTw@mail.gmail.com>
To: Joshua Bell <jsbell@chromium.org>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Mon, Jan 23, 2012 at 5:17 PM, Joshua Bell <jsbell@chromium.org> wrote:
> On Mon, Jan 23, 2012 at 4:12 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
>> In looking at the count method in IDBObjectStore and IDBIndex we noticed
>> that its signature doesn't throw a TransactionInactiveError when the
>> transaction being used is inactive.  We would like to add this to the spec.
> Agreed. FWIW, this matches Chrome's behavior.

Same here.

>> In addition, the index method in IDBObjectStore uses InvalidStateError to
>> convey two different meanings: the object has been removed or deleted and
>> the transaction being used finished.  It seems that it would be better to
>> separate these into:
>> * InvalidStateError when the source object has been removed or deleted.
>> * TransactionInactiveError when the transaction being used is inactive.
>> What do you think?  I can open a bug if we agree this is the desired
>> behavior.
> Did this come out of the discussion here:
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.html
> If so, the rationale for which exception type to use is included, although
> no-one on the thread was deeply averse to the alternative. If it's a
> different issue can give a more specific example?

Right. I think InvalidStateErr is better, for the reason detailed in
the above referenced email.

I agree we're using the same exception for two error conditions, but
I'm not terribly worried that this will make debugging harder for

But I don't feel strongly so if there's a good reason I'm ok with
changing things.

/ Jonas
Received on Tuesday, 24 January 2012 04:22:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC