W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [File API] Issue 182 about OperationNotAllowed

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 3 Oct 2011 15:59:18 -0700
Message-ID: <CA+c2ei-vrWe3qyNofX1pM=CyUYTMquxss1BDHRRydgEtcKX5Uw@mail.gmail.com>
To: arun@mozilla.com
Cc: Anne van Kesteren <annevk@opera.com>, Adrian Bateman <adrianba@microsoft.com>, Arthur Barstow <art.barstow@nokia.com>, Jonas Sicking <sicking@mozilla.com>, public-webapps <public-webapps@w3.org>
On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> On 10/3/11 4:59 PM, Jonas Sicking wrote:
>> On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan<arun@mozilla.com>
>>  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.

Yup. I do wonder if we should introduce a DOMError class which can be
reused in various cases which need APIs like this. IndexedDB could
also use it and I seem to recall that HTML5 does too.

>> 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?

I'll leave this one for Anne. I personally don't care where the new
strings are defined. Anne seemed to prefer to do it in the DOM4 (aka
DOM Core) spec, but I don't think we want to block on that happening.

/ Jonas
Received on Monday, 3 October 2011 23:00:19 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC