You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by Mihai Chira <mi...@gmail.com> on 2014/06/25 13:53:07 UTC
Why can't we try-catch errors thrown from event handlers?
Today I stumbled upon what feels like strange behaviour. In short, if
there's an Error thrown in an event listener, it won't be caught in
the catch block of the code that dispatched the event. Instead, it
will be dispatched by the uncaughtErrorEvents property of LoaderInfo.
(See the code below.)
Does this imply that event dispatching is asynchronous? Despite that
the stack traces always include the event dispatching, and thus seem
to imply it's synchronous? Or just the fact that it happens at a lower
level (within the C++ code of the flash player, perhaps?) impacts
try-catch blocks?
In any case, I think it would really help if we updated the
documentation under LoaderInfo.uncaughtErrorEvents [1] and the
description of the UncaughtErrorEvents class [2] to include this.
[1] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/LoaderInfo.html#uncaughtErrorEvents
[2] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/UncaughtErrorEvents.html
CODE:
<?xml version="1.0" encoding="utf-8"?>
<s:WindowedApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:local="*"
windowComplete="windowedapplication1_creationCompleteHandler(event)"
width="800" height="600">
<fx:Script>
<![CDATA[
import mx.events.AIREvent;
protected function
windowedapplication1_creationCompleteHandler(event:AIREvent):void
{
loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR,
handleUncaughtClientError);
addEventListener("throwErrorPlease", onTestDispatched);
}
protected function onTestDispatched(event:Event):void
{
throw(new Error("juust testin'"));
}
protected function handleUncaughtClientError(event:UncaughtErrorEvent):void
{
trace("uncaught:" + event.error);
}
protected function button1_clickHandler(event:MouseEvent):void
{
try {dispatchEvent(new Event("throwErrorPlease"));}
catch(e:Error)
{
trace("caught:" + e);
}
}
]]>
</fx:Script>
<s:Button label="throw" click="button1_clickHandler(event)"/>
</s:WindowedApplication>
Re: Why can't we try-catch errors thrown from event handlers?
Posted by Mihai Chira <mi...@gmail.com>.
Thanks, Alex. I've opened a feature request with Adobe[1] for this. If
people think it would be useful, please vote for it.
[1] https://bugbase.adobe.com/index.cfm?event=bug&id=3809613
On 8 August 2014 21:26, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 8/8/14 9:07 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>
>>Done.
>>
>>As mentioned in this comment[1], I was wondering if we could also
>>contact someone from Adobe about including this information in the
>>asdoc pages for LoaderInfo.uncaughtErrorEvents. Any ideas who?
> File a bug at bugbase.adobe.com.
>
>>
>>Also, do do we regenerate our asdocs[2] on each release? This would
>>mean that this commit didn't make it for 4.13, I guess?
> Yes, that commit was after the last release candidate for 4.13.
>
> -Alex
>
Re: Why can't we try-catch errors thrown from event handlers?
Posted by Alex Harui <ah...@adobe.com>.
On 8/8/14 9:07 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>Done.
>
>As mentioned in this comment[1], I was wondering if we could also
>contact someone from Adobe about including this information in the
>asdoc pages for LoaderInfo.uncaughtErrorEvents. Any ideas who?
File a bug at bugbase.adobe.com.
>
>Also, do do we regenerate our asdocs[2] on each release? This would
>mean that this commit didn't make it for 4.13, I guess?
Yes, that commit was after the last release candidate for 4.13.
-Alex
Re: Why can't we try-catch errors thrown from event handlers?
Posted by Mihai Chira <mi...@gmail.com>.
Done.
As mentioned in this comment[1], I was wondering if we could also
contact someone from Adobe about including this information in the
asdoc pages for LoaderInfo.uncaughtErrorEvents. Any ideas who?
Also, do do we regenerate our asdocs[2] on each release? This would
mean that this commit didn't make it for 4.13, I guess?
[1] https://issues.apache.org/jira/browse/FLEX-34385?focusedCommentId=14060641&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14060641
[2] http://flex.apache.org/asdoc/index.html
On 26 June 2014 17:16, Mihai Chira <mi...@gmail.com> wrote:
> Cool, and thanks for the guidelines.
>
> On 26 June 2014 16:49, Alex Harui <ah...@adobe.com> wrote:
>> No objection from me. For simple, easily reversible code changes, I just
>> do them and let folks object when they see the commit email. Otherwise, I
>> try to let an email sit about 24 hours, then go and do it. For big
>> things, I try to warn folks up front as I start on it.
>>
>> On 6/26/14 8:35 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>
>>>Cool, thanks for the explanation. I'm happy to take this[1] on, if we
>>>agree it's worth doing (I definitely think it is).
>>>
>>>[1] https://issues.apache.org/jira/browse/FLEX-34385
>>>
>>>On 26 June 2014 05:49, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>
>>>> On 6/25/14 4:53 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>>
>>>>>Today I stumbled upon what feels like strange behaviour. In short, if
>>>>>there's an Error thrown in an event listener, it won't be caught in
>>>>>the catch block of the code that dispatched the event. Instead, it
>>>>>will be dispatched by the uncaughtErrorEvents property of LoaderInfo.
>>>>>(See the code below.)
>>>> Yep, that is expected behavior. I believe it has to do with the
>>>> stack/activationObject getting lost in the player's dispatchEvent code.
>>>> I
>>>> think there are other cases where, if you call into the player and the
>>>> player calls more ActionScript that you can't catch errors in that AS.
>>>>>
>>>>>Does this imply that event dispatching is asynchronous? Despite that
>>>>>the stack traces always include the event dispatching, and thus seem
>>>>>to imply it's synchronous? Or just the fact that it happens at a lower
>>>>>level (within the C++ code of the flash player, perhaps?) impacts
>>>>>try-catch blocks?
>>>> No, event dispatching is synchronous.
>>>>>
>>>>>In any case, I think it would really help if we updated the
>>>>>documentation under LoaderInfo.uncaughtErrorEvents [1] and the
>>>>>description of the UncaughtErrorEvents class [2] to include this.
>>>> Well, we can't since that's a player API. UIComponent does wrap
>>>> dispatchEvent so you could add some documentation there. Or we could
>>>> start a Wiki page of "Nasty Issues". You are now a committer. Go for
>>>>it!
>>>>
>>>> -Alex
>>>>
>>
Re: Why can't we try-catch errors thrown from event handlers?
Posted by Mihai Chira <mi...@gmail.com>.
Cool, and thanks for the guidelines.
On 26 June 2014 16:49, Alex Harui <ah...@adobe.com> wrote:
> No objection from me. For simple, easily reversible code changes, I just
> do them and let folks object when they see the commit email. Otherwise, I
> try to let an email sit about 24 hours, then go and do it. For big
> things, I try to warn folks up front as I start on it.
>
> On 6/26/14 8:35 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>
>>Cool, thanks for the explanation. I'm happy to take this[1] on, if we
>>agree it's worth doing (I definitely think it is).
>>
>>[1] https://issues.apache.org/jira/browse/FLEX-34385
>>
>>On 26 June 2014 05:49, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>
>>> On 6/25/14 4:53 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>
>>>>Today I stumbled upon what feels like strange behaviour. In short, if
>>>>there's an Error thrown in an event listener, it won't be caught in
>>>>the catch block of the code that dispatched the event. Instead, it
>>>>will be dispatched by the uncaughtErrorEvents property of LoaderInfo.
>>>>(See the code below.)
>>> Yep, that is expected behavior. I believe it has to do with the
>>> stack/activationObject getting lost in the player's dispatchEvent code.
>>> I
>>> think there are other cases where, if you call into the player and the
>>> player calls more ActionScript that you can't catch errors in that AS.
>>>>
>>>>Does this imply that event dispatching is asynchronous? Despite that
>>>>the stack traces always include the event dispatching, and thus seem
>>>>to imply it's synchronous? Or just the fact that it happens at a lower
>>>>level (within the C++ code of the flash player, perhaps?) impacts
>>>>try-catch blocks?
>>> No, event dispatching is synchronous.
>>>>
>>>>In any case, I think it would really help if we updated the
>>>>documentation under LoaderInfo.uncaughtErrorEvents [1] and the
>>>>description of the UncaughtErrorEvents class [2] to include this.
>>> Well, we can't since that's a player API. UIComponent does wrap
>>> dispatchEvent so you could add some documentation there. Or we could
>>> start a Wiki page of "Nasty Issues". You are now a committer. Go for
>>>it!
>>>
>>> -Alex
>>>
>
Re: Why can't we try-catch errors thrown from event handlers?
Posted by Alex Harui <ah...@adobe.com>.
No objection from me. For simple, easily reversible code changes, I just
do them and let folks object when they see the commit email. Otherwise, I
try to let an email sit about 24 hours, then go and do it. For big
things, I try to warn folks up front as I start on it.
On 6/26/14 8:35 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>Cool, thanks for the explanation. I'm happy to take this[1] on, if we
>agree it's worth doing (I definitely think it is).
>
>[1] https://issues.apache.org/jira/browse/FLEX-34385
>
>On 26 June 2014 05:49, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>> On 6/25/14 4:53 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>
>>>Today I stumbled upon what feels like strange behaviour. In short, if
>>>there's an Error thrown in an event listener, it won't be caught in
>>>the catch block of the code that dispatched the event. Instead, it
>>>will be dispatched by the uncaughtErrorEvents property of LoaderInfo.
>>>(See the code below.)
>> Yep, that is expected behavior. I believe it has to do with the
>> stack/activationObject getting lost in the player's dispatchEvent code.
>> I
>> think there are other cases where, if you call into the player and the
>> player calls more ActionScript that you can't catch errors in that AS.
>>>
>>>Does this imply that event dispatching is asynchronous? Despite that
>>>the stack traces always include the event dispatching, and thus seem
>>>to imply it's synchronous? Or just the fact that it happens at a lower
>>>level (within the C++ code of the flash player, perhaps?) impacts
>>>try-catch blocks?
>> No, event dispatching is synchronous.
>>>
>>>In any case, I think it would really help if we updated the
>>>documentation under LoaderInfo.uncaughtErrorEvents [1] and the
>>>description of the UncaughtErrorEvents class [2] to include this.
>> Well, we can't since that's a player API. UIComponent does wrap
>> dispatchEvent so you could add some documentation there. Or we could
>> start a Wiki page of "Nasty Issues". You are now a committer. Go for
>>it!
>>
>> -Alex
>>
Re: Why can't we try-catch errors thrown from event handlers?
Posted by Mihai Chira <mi...@gmail.com>.
Cool, thanks for the explanation. I'm happy to take this[1] on, if we
agree it's worth doing (I definitely think it is).
[1] https://issues.apache.org/jira/browse/FLEX-34385
On 26 June 2014 05:49, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 6/25/14 4:53 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>
>>Today I stumbled upon what feels like strange behaviour. In short, if
>>there's an Error thrown in an event listener, it won't be caught in
>>the catch block of the code that dispatched the event. Instead, it
>>will be dispatched by the uncaughtErrorEvents property of LoaderInfo.
>>(See the code below.)
> Yep, that is expected behavior. I believe it has to do with the
> stack/activationObject getting lost in the player's dispatchEvent code. I
> think there are other cases where, if you call into the player and the
> player calls more ActionScript that you can't catch errors in that AS.
>>
>>Does this imply that event dispatching is asynchronous? Despite that
>>the stack traces always include the event dispatching, and thus seem
>>to imply it's synchronous? Or just the fact that it happens at a lower
>>level (within the C++ code of the flash player, perhaps?) impacts
>>try-catch blocks?
> No, event dispatching is synchronous.
>>
>>In any case, I think it would really help if we updated the
>>documentation under LoaderInfo.uncaughtErrorEvents [1] and the
>>description of the UncaughtErrorEvents class [2] to include this.
> Well, we can't since that's a player API. UIComponent does wrap
> dispatchEvent so you could add some documentation there. Or we could
> start a Wiki page of "Nasty Issues". You are now a committer. Go for it!
>
> -Alex
>
Re: Why can't we try-catch errors thrown from event handlers?
Posted by Alex Harui <ah...@adobe.com>.
On 6/25/14 4:53 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>Today I stumbled upon what feels like strange behaviour. In short, if
>there's an Error thrown in an event listener, it won't be caught in
>the catch block of the code that dispatched the event. Instead, it
>will be dispatched by the uncaughtErrorEvents property of LoaderInfo.
>(See the code below.)
Yep, that is expected behavior. I believe it has to do with the
stack/activationObject getting lost in the player's dispatchEvent code. I
think there are other cases where, if you call into the player and the
player calls more ActionScript that you can't catch errors in that AS.
>
>Does this imply that event dispatching is asynchronous? Despite that
>the stack traces always include the event dispatching, and thus seem
>to imply it's synchronous? Or just the fact that it happens at a lower
>level (within the C++ code of the flash player, perhaps?) impacts
>try-catch blocks?
No, event dispatching is synchronous.
>
>In any case, I think it would really help if we updated the
>documentation under LoaderInfo.uncaughtErrorEvents [1] and the
>description of the UncaughtErrorEvents class [2] to include this.
Well, we can't since that's a player API. UIComponent does wrap
dispatchEvent so you could add some documentation there. Or we could
start a Wiki page of "Nasty Issues". You are now a committer. Go for it!
-Alex