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: Israel Hilerio <israelh@microsoft.com>
Date: Tue, 24 Jan 2012 18:08:50 +0000
To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
CC: "jsbell@chromium.org" <jsbell@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>, Adam Herchenroether <aherchen@microsoft.com>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E4280772E@TK5EX14MBXC113.redmond.corp.microsoft.com>
On Monday, January 23, 2012 8:22 PM, Jonas Sicking wrote:
> 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.

Great!  I'll open a bug.

> >> 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.htm
> > l
> >
> > 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 authors.
> But I don't feel strongly so if there's a good reason I'm ok with changing
> things.
> / Jonas

I agree that InvalidStateErr makes sense here.  The issue we're presenting is the use of one exception for two error conditions.
We just want to remove the ambiguity and cleanup of the language.  We have this issue in the IDBObjectStore.index and IDBTransaction.objectStore methods.

One alternative could be to just leave "InvalidStateError" and remove the "or" clause from the description.
That would leave us with:

1. InvalidStateError - Occurs if a request is made on a source object that has been deleted or removed.

Alternatively, we could add one more exception to capture the "or" clause:

2. TransactionInactiveError - Occurs if the transaction the object store belongs to has finished.

I'm okay with only doing #1, if you all agree.  This simplifies things and captures the idea stated in the reference email.  Let me know what you think.

Received on Tuesday, 24 January 2012 18:09:25 UTC

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