Re: [FileAPI] Result of calling MultipleReads on FileReader

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