On 8/9/16, 3:15 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>The way stopImmediatePropagation is being handled in FlexJS is like this:
>
> try {
> return org.apache.flex.events.EventDispatcher.base(this,
>'dispatchEvent', event);
> } catch (e) {
> if (e.name != "stopImmediatePropagation")
> throw e;
> }
>
>This is proving to be very painful because almost any bug in client code
>will be swallowed by this try/catch and there’s no stack trace to find
>where the error is. (Code execution is almost always wrapped in an event
>handler of some manner, shape or form.)
>
>Is there another way to handle this that will preserve the stack trace on
>errors?
From the code snippet above, I don't see why you wouldn't get an error.
It looks like "e" is still thrown and I thought the stack trace in "e" is
captured on its instantiation not on when it is thrown. Or does the JS
throw re-do the stack trace info?
On the Flash side, I think there is no way to capture errors thrown from
inside event handlers anyway. Not sure how the browsers work in that
regard.
And in the bigger picture, we use Google's event system mainly because it
was the most reliable way to get a single event system across all
browsers, especially IE8 back when we were getting started. But now that
we've dropped IE8, we could revisit using Google's event system. We could
proxy to the wrapped DOM element I think on all browsers we care about
these days, and for an EventDispatcher that doesn't wrap an element, it
might be possible to write or find a simpler event system since on non-DOM
objects, we don't have to worry about bubble/capture. And for the
download-sensitive, IIRC, Google's event system is about a 6K download.
-Alex
