W3C home > Mailing lists > Public > public-web-perf@w3.org > June 2014

Re: [RequestAnimationFrame]: thrown exceptions and user experience

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 23 Jun 2014 13:36:02 -0400
Message-ID: <53A86582.10300@mit.edu>
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.  :(

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:38 UTC