- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 23 Jun 2014 13:36:02 -0400
- To: public-web-perf@w3.org
- CC: Anne van Kesteren <annevk@annevk.nl>
On 6/23/14, 1:22 PM, Jake Verbaten wrote: > > If calling the operation resulted in an exception being thrown, then > catch that exception and ignore it. The exception should be reported as an uncaught exception, and is in at least Chrome and Firefox. The fact that the spec says to ignore it is a spec bug that needs fixing, I agree. However, an exception in a rAF callback should not abort the processing of other pending rAF callbacks, which is what I think your pull request ends up doing. This is a bit of a pain to do in a polyfill because there is no platform primitive for "report this exception as uncaught", so your options are to either let it propagate and abort your code or catch it and then you have no sane way to report it. Anne, do you know if there are existing plans to introduce such a mechanism? It seems like it would be really useful in general... > It seems incredibly unintuitive for a core timing primitive to swallow > and ignore exceptions, this makes debugging incredibly difficult and > painful. Yes, agreed. > For reference point, reading the `setTimeout` specification ( > http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html > ) it sounds like it doesn't do any special exception handling. That's because setTimeout is OK with its steps being aborted on exception, because it has nothing else to do after running the callback. Separate timeouts run from separate tasks on the event loop, and exceptions don't propagate to the event loop. Of course this is not really specified very clearly anywhere. :( -Boris
Received on Monday, 23 June 2014 17:36:31 UTC