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: Tue, 12 Apr 2011 14:44:32 -0400
Message-ID: <4DA49D90.8000502@mozilla.com>
To: Adrian Bateman <adrianba@microsoft.com>
CC: 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:39 PM, Adrian Bateman wrote:
> On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote:
>> On Mon, Apr 11, 2011 at 9:33 AM, 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).
>> I don't think so.  I think that calling two read methods is the kind
>> of thing that will come up in initial testing, the exception won't be
>> caught at all, and thus will be noticed and the bug removed.
>>>   On the main thread, with
>>> your proposal, all reads will stop since an exception has been raised.  Of
>>> course, when all reads are synchronous, throwing makes sense, since we're
>>> not generating events that the developer listens for.  Thus, in the case of
>>> FileReaderSync, I'll introduce spec. text (and more WebIDL formalism) that
>>> makes it clear that multiple reads will raise a FileException.
>> I'd *much* rather have an exception than silently get some random
>> result depending on which method I accidentally called last.
>>>   The burden on the vigilant developer is to watch
>>> for errors, but the developer can at least obtain the result of the latest
>>> read call without an exception.
> I agree with Eric - I prefer to fail fast when the developer has misused an API.
> It makes it much easier to see that there is a mistake and debug why.
> So the key question to me is "Is this misuse?" I can't think of a good use case
> where a developer would want to call read again during the LOADING state and
> expect that the correct behaviour would be to implicitly call abort(). That
> doesn't seem like a common scenario. In the EMPTY or DONE states makes perfect
> sense - that makes FileReader reusable - but during LOADING I think is a developer
> mistake.

I felt it desirable to stick to what XHR does, which is an abort on 
previous calls.  Eric, Adrian: do you both feel we shouldn't be 
consistent with XHR?  If so, an exception makes sense.  But I honestly 
think similarity with XHR is desirable in this case.

-- A*
Received on Tuesday, 12 April 2011 18:45:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC