A way of explicitly reporting exceptions

[Andrea Giammarchi]

I am saying that if your requestAnimationFrame throws mine should keep
working without problems as if your click handler fails mine should still
work properly even if added after yours.

If the problem is being able to reproduce this in JS then there should be
no ticket fired in HTML land and W3C since their behavior is actually
expected and IMO correct since ever.

Here some background explored in 2009:
http://dean.edwards.name/weblog/2009/03/callbacks-vs-events/

It was that time everyone was trying to replicate events behaviors
correctly so it might be useful for your case ;-)

Worth a read


On Mon, Jun 23, 2014 at 1:43 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140623/6a9a022f/attachment.html>