On 10/3/11 4:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan<[email protected]> wrote:
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for the follow-up - you beat me to it. We've been reviewing this in
the context of the other specs and, as Israel outlined for IndexedDB,
we're
happy with the new WebIDL approach.
I think we should go ahead and migrate the File API exceptions to this new
model and use ISSUE-182 to drive that change.
Adrian,
That's great :) Just to clarify from a File API perspective, are you ok
with an OperationNotAllowed exception, *or* are you advocating reuse of
DOMException with OperationNotAllowed like how IndexedDB is doing? I'm
unclear whether I should change what is in the editor's draft now.
A somewhat affiliated question is whether there should be a "message"
attribute in our FileException and OperationNotAllowed exceptions (and in
FileError).
Here are my feelings:
1. Get rid of FileError/OperationNotAllowedException completely. All
exceptions we throw should be DOMExceptions.
2. We should try to reuse as many exceptions as we can from the DOM4 spec.
Eeep! :) This is a big-ish change, but I'm amenable to it, especially
to stay consistent with what IndexedDB is doing (and to be consistent
with HTML/XHR2, etc.). But to be clear, above you mean:
1. Get rid of FileException and OperationNotAllowedException completely,
but you probably do NOT mean get rid of FileError. We'll want to keep
FileError since it's an asynchronously handled error object in onerror,
but we'll reuse whatever we reuse from DOMException, if it makes sense
to do so.
Honestly, implementations are not consistent with respect to what they
throw today with respect to FileException and read-affiliated
exceptions, so if it helps get us some consistency by channeling things
through DOM4 (and WebIDL), I'm okay with it, short term pain of changing
the spec. notwithstanding.
That means that in the places where we throw
OperationNotAllowedException we should throw a DOMException with
.name="InvalidStateError".
OK.
For SECURITY_ERR we'll want to use DOMException with .name="SecurityError"
OK.
For ABORT_ERR we'll want to use DOMException with .name="AbortError"
We don't actually throw an ABORT_ERR, so one thing that's attractive
about making this change is that we'll eliminate redundant codes in
objects we don't actually use.
For NOT_READABLE_ERR I think we'll want to mint a new error. Something
like DOMException with .name="IOError" or some such?
OK. So it's when we need new exception codes, names, and types that the
confusion with this model sets in. While we can add to DOMException in
a decentralized way, do the editors of DOM4 intend to add the new
exceptions to DOMException?
For ENCODING_ERR, I think we'll want to mint a new error. DOMException
with .name="CharsetEncodingError" maybe?
OK (same question).
In the cases where we reuse existing errors, the .code should be set
to the code that the DOM4 spec defines. But I think if we use the
correct vocabulary, the DOM4 spec will take care of that. cc'ing Anne
who helped out with this for IndexedDB recently.
(Commentary from Anne welcome).
-- A*
