[Bug 17681] [IndexedDB] Operations that raise multiple exceptions types should define order

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17681

--- Comment #10 from Joshua Bell <jsbell@chromium.org> ---
(In reply to comment #9)
> I guess there's some value in having a consistent ordering. For example it
> seems surprising that the orders between .add and .delete are so different:
> 
> IDBObjectStore.add(): InvalidStateError > TransactionInactiveError >
> ReadOnlyError > DataError > DataCloneError
> IDBObjectStore.delete(): DataError > InvalidStateError >
> TransactionInactiveError > ReadOnlyError

In Chrome's impl, some of that is completely arbitrary (ordering of tests in
the function), some of it is due to calling overloads (e.g. the overload that
takes keys checks to see if the key is valid first then defers to the range
overload; the range overload checks transaction/object state first...)

> If the transaction-related errors are thrown after the data-related errors
> then it might make it easier to first process the incoming data and then
> call more generic functions that schedule a request against a transaction.
> That's not something that made sense in the current gecko implementation,
> but I could see that being the case elsewhere.

Agreed. Of course, I'd also be fine with the reverse - check that the overall
state is good-to-go, then look at the specific data.

I'll try and run my scripts against IE; if it's ordering is sensible perhaps we
can follow what it does since the other impl's can rev more quickly.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 1 April 2013 19:41:27 UTC