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

Re: [FileAPI] Result of calling MultipleReads on FileReader

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 11 Apr 2011 13:28:45 -0400
Message-ID: <4DA33A4D.1000606@mozilla.com>
To: Glenn Maynard <glenn@zewt.org>
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 4/11/11 1:04 PM, Glenn Maynard wrote:
> On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan <arun@mozilla.com 
> <mailto: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.

The spec. should absolutely say when an exception is raised for 
scenarios that you point out above, and I should add this in (currently 
we don't say anything about that scenario).  I guess the question here 
is what to do in the multiple reads scenario.

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

I'm sorry, I'm misunderstanding.  Seems like the behavior with 
exceptions is that if there are multiple reads, previous ones raise 
exceptions, but that the latest is processed (assuming no errors, 
etc.).  Is that correct?

-- A*
Received on Monday, 11 April 2011 17:29:15 GMT

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