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

Re: [FileAPI] Result of calling MultipleReads on FileReader

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 11 Apr 2011 13:04:00 -0400
Message-ID: <BANLkTikdZMMAR7wbyC0tb1mvoXXx_h5S=g@mail.gmail.com>
To: arun@mozilla.com
Cc: Adrian Bateman <adrianba@microsoft.com>, Eric Uhrhane <ericu@google.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>, Arun Ranganathan <aranganathan@mozilla.com>
On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan <arun@mozilla.com> wrote:

> In general, I'm averse to throwing, since I think it puts an additional
> burden on the developer (to catch, for example).


Only if the developer is trying to catch all exceptions, which you usually
don't.  Most developers don't try to catch exceptions that indicate API
usage errors, like element.appendChild(element); they just let the exception
propagate and fix the bug.

I think it makes sense to throw an exception here.  Callbacks should
indicate the result of a successful call to an async method, but if the
method *itself* (not the async operation it queues) failed, throw.

Note that FileReader methods already throw an exception in Firefox, eg. new
FileReader().readAsBinaryString(null).  I'm not sure if that particular case
is to spec, but it makes a lot more sense than using onerror.

> On the main thread, with your proposal, all reads will stop since an
exception has been raised.

That's odd--why would that happen?  Normally one expects an API call that
throws an exception to have no effect.  It'd be particularly strange if some
exceptions cancel the previous read and others didn't.

-- 
Glenn Maynard
Received on Monday, 11 April 2011 17:04:28 GMT

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