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<a...@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.
-- A*
