On 4/11/11 1:04 PM, Glenn Maynard wrote:
On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan <a...@mozilla.com
<mailto: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).
Only if the developer is trying to catch all exceptions, which you
usually don't. Most developers don't try to catch exceptions that
indicate API usage errors, like element.appendChild(element); they
just let the exception propagate and fix the bug.
I think it makes sense to throw an exception here. Callbacks should
indicate the result of a successful call to an async method, but if
the method *itself* (not the async operation it queues) failed, throw.
Note that FileReader methods already throw an exception in Firefox,
eg. new FileReader().readAsBinaryString(null). I'm not sure if that
particular case is to spec, but it makes a lot more sense than using
onerror.
The spec. should absolutely say when an exception is raised for
scenarios that you point out above, and I should add this in (currently
we don't say anything about that scenario). I guess the question here
is what to do in the multiple reads scenario.
> On the main thread, with your proposal, all reads will stop since an
exception has been raised.
That's odd--why would that happen? Normally one expects an API call
that throws an exception to have no effect. It'd be particularly
strange if some exceptions cancel the previous read and others didn't.
I'm sorry, I'm misunderstanding. Seems like the behavior with
exceptions is that if there are multiple reads, previous ones raise
exceptions, but that the latest is processed (assuming no errors,
etc.). Is that correct?
-- A*