W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [FileAPI] Updates to FileAPI Editor's Draft

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 8 Jun 2011 11:24:06 -0700
Message-ID: <BANLkTikrQiiX5uE-LOaGt-cq5TgN+fqgaxeXrS2i47wgTt-QFw@mail.gmail.com>
To: Robin Berjon <robin@berjon.com>
Cc: arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
On Wed, Jun 8, 2011 at 8:16 AM, Robin Berjon <robin@berjon.com> wrote:
> On May 12, 2011, at 00:49 , Arun Ranganathan wrote:
>> 2. The read methods on FileReader raise a new exception -- OperationNotAllowedException -- if multiple concurrent reads are invoked.  I talked this over with Jonas; we think that rather than reuse DOMException error codes (like INVALID_STATE_ERR), these kinds of scenarios should throw a distinct exception.  Some things on the web (as in life) are simply not allowed.  It may be useful to reuse this exception in other places.
>
> I don't have a strong opinion on the ISSUE-182 side of this, but if we're going to create a new exception type that is expected to be reused by other specs can we at least learn from the past and not use numerical codes to identify different variants of the same exception (I'm presuming that other specs reusing this could want to be more precise about why the operation is not allowed, e.g. "user said no", or "Gandalf doesn't want you to pass")? Reuse of DOMException was a long and at times painful coordination effort to make sure that people didn't use the same codes in their own extensions.

Yes. These should definitely not have a .code property unless needed
for backwards compatibility (which shouldn't be the case for
exceptions thrown by FileAPI, unless we want to share them with
DOM-Core methods).

/ Jonas
Received on Wednesday, 8 June 2011 18:25:03 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT