RE: [indexeddb] Exception type for NON_TRANSIENT_ERR code

On Monday, October 03, 2011 7:18 PM, Jonas Sicking wrote:
> 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

Sounds reasonable!  I'll make sure we include these changes when we update the spec.
Thanks,

Israel

Received on Friday, 7 October 2011 22:26:25 UTC