- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 29 May 2012 02:31:35 -0700
- 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