On Mon, Apr 11, 2011 at 12:33 PM, 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). 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. > 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. -- Glenn Maynard
Received on Monday, 11 April 2011 17:04:28 UTC