A way of explicitly reporting exceptions

Boris Zbarsky bzbarsky at MIT.EDU
Mon Jun 23 13:43:18 PDT 2014

On 6/23/14, 4:35 PM, Andrea Giammarchi wrote:
> I personally don't think it's DOM responsibility to clean up after
> "your" errors

If I follow you correctly, what you're saying is that if there's some 
buggy ad on the web page that uses requestAnimationFrame and throws in 
the callback, then all other uses of requestAnimationFrame on the web 
page should stop working.  Or keep working, depending on how they happen 
to race with the ad in terms of the ordering in the callback list.  Or 
randomly work or not work on alternate page reloads.

I think convincing people to _switch_ to such a behavior from the 
current is impossible.  Even convincing them to implement such a 
behavior for new features is a touch sell.

But is that what you're really saying?  I can't tell.

> and I'd expect DOM to keep firing if a listener set by
> some other library or scope I don't know/own fails, as it has always been.

I'm really not sure what you're talking about here, even after your 
clarification mail.

> The most common Web scenario is where different libraries expect
> different behaviors from same handlers set on elements shared and
> reachable globally ... I'd rather not interfere with a generic listener
> and handlers stack I don't personally own from my code.

OK.  Who suggested interfering with anything?

What my mail said is that browsers currently implement a behavior that's 
impossible to implement in the ES language proper, and that it might be 
desirable to have a way to implement that behavior in ES proper.


More information about the es-discuss mailing list