W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: IndexedDB: ambiguity around IDBTransaction.error

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 29 May 2012 02:31:35 -0700
Message-ID: <CA+c2ei8D=_2ccXvb8mo=OEvPvG3ke2ZJy2C5QPc6VsJu4v454g@mail.gmail.com>
To: Alec Flett <alecflett@google.com>
Cc: public-webapps@w3.org
On Fri, May 25, 2012 at 1:16 PM, Alec Flett <alecflett@google.com> wrote:
> I have found what feels like an ambiguity in the spec around
> IDBTransaction..error and when it is available.
> In particular, the spec says:
>> When the done flag is true, getting this property must return the error of
>> the request that caused the transaction to be aborted. [...] When
>> the done flag is false, getting this property must throw a DOMException of
>> type InvalidStateError.
> The ambiguity here is that the 'done flag' is technically something that
> resides on the request, not the transaction. After the transaction itself is
> complete, the 'error' attribute should be the error that caused the
> transaction to abort, if any. So the question is, which 'done' flag does
> this correspond to - the done flag on the current request, the done flag on
> the request that caused the abort, or some other 'done' state about the
> transaction itself.
> An example:
> transaction = ...
> transaction.objectStores("foo").put(badValue).onerror = function(event) {
>   // can I access transaction.error here?
>   // the request has its own error though.
>   requestError = event.target.error;
>   transaction.objectStores("foo").put(goodValue).onsuccess =function(event)
> {
>   // can I access transaction.error here? If so, is it requestError, or is
> it null?
>   }
> }
> transaction.objectStores("foo").put(goodValue).onsuccess =
> As a consumer of this interface, I'd expect the transaction's error property
> to be set early - i.e. available as soon as the error handler fires, above,
> and then I'd expect it to remain unchanged for the duration of the rest of
> the transaction. But I can see arguments against that. For instance, what
> happens if preventDefault() is called? we need to avoid setting the error in
> that case.. I think. So that would argue for some kind of 'done' flag /
> state for the transaction itself.
> Thoughts?

We have the 'finished' flag already, which I think is what we should
use here. Unfortunately it's somewhat ambigious when a transaction
becomes finished.

Would you mind filing a bug on this?

/ Jonas
Received on Tuesday, 29 May 2012 09:37:20 UTC

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