BTW: If we look at getting rid of goog.events, we might want to look at getting rid of goog.inherits and goog.base as well.
For IE9+, I think we can use Object.create() instead.[1] [1]https://developer.mozilla.org/en/docs/Web/JavaScript/Inheritance_and_the_prototype_chain On Aug 9, 2016, at 6:39 PM, Harbs <harbs.li...@gmail.com> wrote: > 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 >> >
