Re: [FileAPI] Result of calling MultipleReads on FileReader

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*

Received on Monday, 11 April 2011 16:34:20 UTC