Re: [FileAPI] Result of calling MultipleReads on FileReader

On Mon, Apr 11, 2011 at 10:39 AM, Adrian Bateman <adrianba@microsoft.com> 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.

FileReader is extremely similar to XMLHttpRequest. The main difference
is in how you initiate the request (.open/.send vs. .readAsX). This
similarity is even getting stronger now that XHR gets .result.

So I think there are good reasons to sticking to XMLHttpRequest here too.

Note that no "error" events are fired by XMLHttpRequest. Just an
"abort" event. So "error" is still reserved for actual reading errors
whereas "abort" will fire for script-initiated aborts.

I agree that calling .readAsX multiple times could be an indication of
developer bugs and as such could throw an exception. However I think
given the precedence set by XMLHttpRequest it could just as well mean
that a new resource is now the one that the author is interested in
reading.

/ Jonas

Received on Tuesday, 12 April 2011 19:08:40 UTC