RE: [FileAPI] Result of calling MultipleReads on FileReader

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.

Cheers,

Adrian.

Received on Monday, 11 April 2011 17:39:39 UTC