Return-Path: X-Original-To: apmail-flex-issues-archive@minotaur.apache.org Delivered-To: apmail-flex-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 53C0910DE6 for ; Wed, 23 Apr 2014 09:36:21 +0000 (UTC) Received: (qmail 23438 invoked by uid 500); 23 Apr 2014 09:36:20 -0000 Delivered-To: apmail-flex-issues-archive@flex.apache.org Received: (qmail 23373 invoked by uid 500); 23 Apr 2014 09:36:19 -0000 Mailing-List: contact issues-help@flex.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flex.apache.org Delivered-To: mailing list issues@flex.apache.org Received: (qmail 23241 invoked by uid 99); 23 Apr 2014 09:36:15 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Apr 2014 09:36:15 +0000 Date: Wed, 23 Apr 2014 09:36:15 +0000 (UTC) From: "Mihai Chira (JIRA)" To: issues@flex.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (FLEX-33747) LayoutManager does not fail gracefully if error thrown as a result of its code MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/FLEX-33747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978031#comment-13978031 ] Mihai Chira commented on FLEX-33747: ------------------------------------ Indeed, [~jmclean], this comment on FLEX-15925 implies that catchCallLaterExceptions will help fix the problem: "If you are willing to take the performance hit, you can use the UIComponentGlobals.catchCallLaterExceptions flag to find out if there was an error during any callLater callback." I updated the sample project to include UIComponentGlobals.catchCallLaterExceptions=true, and to listen to "callLaterError". LayoutManager fails to draw components on stage, just as before. > LayoutManager does not fail gracefully if error thrown as a result of its code > ------------------------------------------------------------------------------ > > Key: FLEX-33747 > URL: https://issues.apache.org/jira/browse/FLEX-33747 > Project: Apache Flex > Issue Type: Bug > Components: Layout - General > Affects Versions: Apache Flex 4.10.0 > Environment: Windows 8 > Apache Flex SDK 4.10 > Reporter: Mihai Chira > Labels: easytest > Fix For: Apache Flex 4.11.0 > > Attachments: _ByeByeCreationComplete.fxp > > > Compile and run the attached project. > If the checkbox is selected, an error is thrown that stops future validation of the stage and prevents new components to have the .initialized flag set to true (which is the prerequisite for having their CREATION_COMPLETE event thrown. Lots of frameworks depend on this event for mediator initialization and others). > If the checkbox is not selected and you then click on the "Throw Error" button, then a similar error as before is thrown which does not prevent future execution of LayoutManager or other key framework components. As a result, the error dialogue is correctly shown with a green rectangle on the top to indicate that it had its CREATION_COMPLETE event thrown. > I'm not exactly sure whether this is a bug per se, but from looking at LayoutManager.validateClient, it appears that it is possible for this function to fail gracefully and continue normal execution when an error is thrown in the middle of its while() loop. I tried using a try/catch block which caught the error, allowed the last if block execute (which sets initialized to true), then threw the error again. This worked slightly better than not having it, but still future validations would not happen unless validateNow() was called on various components. > What I haven't tried is to empty the invalidatePropertiesQueue or reset other important variables. But I really don't know enough about the LayoutManager to implement such changes. > The reason I'm opening this is that I've been investigating a bug that would open an empty dialogue in our application, and the reason the dialogue was not showing the error was all the above. -- This message was sent by Atlassian JIRA (v6.2#6252)