W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

RE: [FileAPI] Result of calling MultipleReads on FileReader

From: Adrian Bateman <adrianba@microsoft.com>
Date: Mon, 11 Apr 2011 17:39:07 +0000
To: Eric Uhrhane <ericu@google.com>, "arun@mozilla.com" <arun@mozilla.com>
CC: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>, Arun Ranganathan <aranganathan@mozilla.com>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB3D31EC82@TK5EX14MBXC136.redmond.corp.microsoft.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:44 GMT