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.
-Boris
More information about the es-discuss
mailing list