On 4/11/11 12:05 PM, Adrian Bateman 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.
In general, I'm averse to throwing, since I think it puts an additional
burden on the developer (to catch, for example). 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. 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'm absolutely resolved to providing better specification text, but I'm
pushing back on the matter of throwing on the main thread, since I
believe it may actually be easier. In both scenarios, we don't allow
for multiple simultaneous reads (e.g. you can't simultaneously read as
text and as binary).
Do you disagree strongly?
-- A*
