Re: IndexedDB: use of TypeError

On Tue, May 29, 2012 at 9:49 AM, Alec Flett <alecflett@google.com> wrote:
> So I didn't start working on/implementing indexedDB until after this message
> went out:
>
> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0958.html
>
> So I haven't had to face the full implications of using TypeError until this
> week.
>
> I'd like to (hopefully not too late) voice my opposition to TypeError for
> the following scenarios:
>
> invalid value for the 'direction' parameter to open*Cursor (must be 'next',
> 'prev', 'nextunique', or 'prevunique')
> advance(count) where count < 1
> open(version) where version < 1
>
> The problem here is that these are not easily enforceable by the WebIDL
> spec, which means implementations have an extra burden of customizing their
> WebIDL implementation to custom-annotate the IDL extend things like
> [EnforceRange=Positive] or introducing JS semantics into their otherwise
> JS-free code.
>
> Now this certainly could just be an implementors complaint, but I feel like
> I can retroactively justify it:
>
> The rationale behind the current spec is that these are very similar to a
> "range error" where the API has a very narrow range of values, that precede
> any higher level semantic parameter constraints. But the problem is that
> they still have some semantic value within IndexedDB - i.e. even though '0'
> is a valid numeric value to JavaScript, it is invalid because of specific
> consistencies within the IndexedDB spec. Even though "foo" is a valid string
> to JavaScript, strings like "next" and "prev" are the only valid strings
> because they have specific meaning in the context of IndexedDB.
>
> So I'd argue that these errors should be indexeddb-specific errors, and/or
> reused DOMExceptions. What I miss is the NotAllowedError that I believe in
> an earlier version of the spec, but I could also believe that DOMException's
> InvalidAccessError could also be used ("The object does not support the
> operation or argument")

The open*Cursor exception should be enforcable using WebIDL by using
an enum. The only reason we don't have it that way in the spec is
because ReSpec doesn't support that.

For the other exception, I would say that it seems weird if -1 threw
one error and 0 threw another one, so I'd like to stick to the current
spec. There is of course also the fact that the requested change
doesn't obviously make it better for web developers and that it's late
in the game to make this change.

What we've done in Gecko is to create a special C++ error code which
turn into a TypeError by the JS-glue layer. That way we don't have to
add new WebIDL annotations but we also don't have to introduce JS-isms
into the C++ code. I suspect more specs will end up throwing TypeError
so that solution seems good for future proofing.

/ Jonas

Received on Tuesday, 29 May 2012 21:50:21 UTC