You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2016/08/09 10:15:21 UTC
FlexJS stopImmediatePropagation
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?
Re: FlexJS stopImmediatePropagation
Posted by Harbs <ha...@gmail.com>.
That’s fine. We’re long overdue on a release.
I would like to merge it into develop as soon as we cut the release branch though.
On Aug 9, 2016, at 7:28 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>> 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… ;-)
>
> I'm tempted to cut a release before we merge in sprite-refactor. Peter is
> looking into the examples now, but I think there is going to be a fair
> amount of debugging to be done. Or do you think the code-intelligence
> changes are really going to be a huge improvement to folks?
Re: FlexJS stopImmediatePropagation
Posted by Alex Harui <ah...@adobe.com>.
On 8/9/16, 8:59 AM, "Harbs" <ha...@gmail.com> wrote:
>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.
IMO, goog.events is separate from goog.inherits and goog.base. Erik would
know best, but I think the GCC optimizer understands goog.inherits and
goog.base. It doesn't care about goog.events. Someone is welcome to
write an emitter that uses different amounts of goog.
>
>On Aug 9, 2016, at 6:39 PM, Harbs <ha...@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).
Actually, in reading up on JS error, I don't think there is a
getStackTrace() call. What happens if you set a break point on that catch
line? Would that be a useful best practice when debugging or just too
painful?
>>
>> 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 didn't think Promises had anything to do with events.
>>
>> 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… ;-)
I'm tempted to cut a release before we merge in sprite-refactor. Peter is
looking into the examples now, but I think there is going to be a fair
amount of debugging to be done. Or do you think the code-intelligence
changes are really going to be a huge improvement to folks?
-Alex
Re: FlexJS stopImmediatePropagation
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ah...@adobe.com> wrote:
>
>>
>>
>> On 8/9/16, 3:15 AM, "Harbs" <ha...@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
>>
>
Re: FlexJS stopImmediatePropagation
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com> wrote:
>
>
> On 8/9/16, 3:15 AM, "Harbs" <ha...@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
>
Re: FlexJS stopImmediatePropagation
Posted by Alex Harui <ah...@adobe.com>.
On 8/9/16, 3:15 AM, "Harbs" <ha...@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