Re: [RequestAnimationFrame]: thrown exceptions and user experience

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 (
> ) 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.  :(


Received on Monday, 23 June 2014 17:36:31 UTC