Re: [indexeddb] Exception type for NON_TRANSIENT_ERR code

On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
>> For several of these I think we can reuse existing DOMExceptions.
>> Here's how I'd map the exceptions which are currently in the IndexedDB
>> spec:
>>
>> UNKNOWN_ERR
>> Mint a new UnknownError. Alternatively we could simply throw an
>> ECMAScript Error object with no more specific type.
>>
>> NON_TRANSIENT_ERR
>> I think in many cases we should simply throw a TypeError here. That seems
>> to match closely to how TypeError is used by WebIDL now.
>
> As I'm mapping the Exception codes to the new Exception type model, I thought we should mint a new type for NON_TRANSIENT_ERR, NonTransientError.  The reason is that TypeError seems to be designed to cover all intrinsic conversion cases and NON_TRANSIENT_ERR seems to be dealing with additional validation beyond what TypeError normally checks for.  This will also allow us to assign a code value of 0 and a message: "This error occurred because an operation was not allowed on an object. A retry of the same operation would fail unless the cause of the error is corrected."

The reason I'm not a fan of NonTransientError is that it doesn't
really mean anything. All it says is "you'd get the same error if you
tried the operation again". However that is true for almost all
exceptions in any DOM spec. The only case that I can think of where
that isn't the case is when using the synchronous IndexedDB API or
when using synchronous XHR.send and there is a IO or network error.

I looked through the spec and came up with this list for when we're
currently throwing NON_TRANSIENT_ERR and I agree that not in all of
them it makes sense to use TypeError. Here is what I came up with:

IDBFactory.cmp if either key is not a valid key
  This should throw DataError per Joshua's email.

IDBDatabase(Sync).createObjectStore if the keypath argument contains
an invalid keypath
  This best fit here seems to be "SyntaxError" in DOMException.

IDBDatabase(Sync).createObjectStore if the options argument is handed
an object with properties other than those in the dictionary.
  This doesn't actually match how dictionaries are supposed to behave
per WebIDL. They are defined to ignore all properties not defined by
the dictionary IDL. So we should remove this exception and also change
the type of this argument to use "IDBDatabaseOptionalParameters"
rather than "Object".

IDBDatabase(Sync).transaction when passed an invalid mode
  I think other specs throw a TypeError in similar situations, but
can't think of any examples off the top of my head.

IDBObjectStore(Sync).createIndex if the keypath argument contains an
invalid keypath
  Same as for createObjectStore

IDBObjectStore(Sync).createIndex if the options argument is handed an
object with properties other than those in the dictionary.
  Same as for createObjectStore

IDBCursor(Sync).advance if passed a negative or zero value
  WebIDL throws TypeError in other similar out-of-range situations

Let me know what you think.

/ Jonas

Received on Tuesday, 4 October 2011 02:18:47 UTC