Re: [IndexedDB] Reason for aborting transactions

> I think that's what Ben was suggesting.

Yes. We already have ABORT_ERR, no reason we can't subdivide that
since it's being overloaded. In fact I think it makes perfect sense.

> Add the following to IDBTransaction:

I'm really not a fan of making IDBTransaction more complicated. We
already have a generic "tell me when something goes wrong, and why"
mechanism via errorCode and onError/onAbort. Why add another one? If
the name is confusing we could rename it to exceptionCode perhaps?

>   readonly attribute abortMessage;

We dropped errorMessage already, let's not add abortMessage.

> And just set the message/code right before firing an abort event.

And what happens when someone calls .abortCode before the transaction
has finished? Or if the transaction succeeded? Or if the transaction
failed for some other reason? I think we'd probably want the same
behavior as calling .errorCode, so again I think we should just roll
the specific abort reasons into error codes and stick with our
existing mechanism.

-Ben

Received on Tuesday, 8 February 2011 19:38:03 UTC