Re: [FileAPI] Result of calling MultipleReads on FileReader

On Tue, Apr 12, 2011 at 11:44 AM, Arun Ranganathan <arun@mozilla.com> wrote:
> 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.

I'd rather have an exception, and no interruption to the read already
in progress.  I don't think similarity with XHR, which is already
somewhat different, is worth the cost.

	Eric

Received on Tuesday, 12 April 2011 19:04:47 UTC