On 4/11/11 1:04 PM, Glenn Maynard wrote: > On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan <arun@mozilla.com > <mailto: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. 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*
Received on Monday, 11 April 2011 17:29:15 UTC