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

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

           Summary: [IndexedDB] Operations that raise multiple exceptions
                    types should define order
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Indexed Database API
        AssignedTo: dave.null@w3.org
        ReportedBy: jsbell@chromium.org
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org


(This has been discussed before, but I didn't see a tracking bug.)

Example: The description of IDBDatabase.transaction() says:

If this method is called on IDBDatabase object for which a "versionchange"
transaction is still running, a InvalidStateError exception must be thrown.... 
Likewise, if this method is called on a IDBDatabase instance where the
closePending flag is set, a InvalidStateError exception must be thrown.

Followed by the table:

InvalidStateError     The close() method has been called on this IDBDatabase
instance.
NotFoundError    One of the names provided in the storeNames argument doesn't
exist in this database.
TypeError    The value for the mode parameter is invalid.
InvalidAccessError    The function was called with an empty list of store names

In the case where multiple conditions apply that would result in an exception
being thrown, the order is undefined. For example:

db.transaction("no-such-store", "invalid-mode"); // TypeError or NotFoundError?
db.close() && db.transaction([], "invalid-mode"); // InvalidStateError,
InvalidAccessError or TypeError?

The specification should enumerate the conditions in a well defined order so
that different implementations will behave consistently.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 3 July 2012 21:00:10 UTC