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" <[email protected]> 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 <[email protected]> wrote: >> >> >> On 6/25/14 4:53 AM, "Mihai Chira" <[email protected]> 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 >>
