Re: [FileAPI] Result of calling MultipleReads on FileReader

On Mon, Apr 11, 2011 at 9:05 AM, Adrian Bateman <adrianba@microsoft.com> wrote:
> On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote:
>> On 3/31/11 6:12 PM, Eric Uhrhane wrote:
>> > I think it's cleaner and simpler just to throw.  FileReader and XHR
>> > are already different enough that a bit more, as long as it's a
>> > usability improvement, isn't a big deal.  The efficiency improvement
>> > is just a bonus.
>>
>> Eric: are you sure you mean "throw" or do you mean, fire error event or
>> abort?  Note that only FileReaderSync (running on threads) actually
>> "throws" in terms of an exception.
>
> I think throwing an exception would be appropriate here. The FileReader
> will know synchronously that it is already doing a read and that calling
> read again is an invalid operation. Firing the error event should be
> reserved for errors that come from the operation of the reader and not
> because the developer called it incorrectly.

My thoughts exactly.  That's the way I've structured things in
FileWriter as well.  I think it's much better to find out about bad
code as soon as possible.

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.
>
> On the main thread, what we have now (which, as you correctly point out,
> needs to be better defined) is that the previous read aborts, but the latest
> call goes through.  I like this since at least some result is obtained,
> rather than an exception.

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.

Received on Monday, 11 April 2011 17:24:06 UTC