You do get an error, but the error loses the stack. All you have is the
function which threw the event, but you have no trace of the object which
handled the event (and caused the error).
I have no idea why this is so. I assume it has to do with “callback hell” and
the callbacks which the event system uses.
If we do redo the event system we might want to use Promises instead.
I’d like to get to the point where we can merge the sprite-refactor branch back
into develop before we start fixing other things, though… ;-)
Harbs
On Aug 9, 2016, at 5:41 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> 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
>
