On Tue, May 29, 2012 at 9:49 AM, Alec Flett alecfl...@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
