Skip navigation
Currently Being Moderated

How to handle errors if error component doesn't exist yet

Mar 22, 2013 11:52 AM

Traditionally, when I encapsulate code in a <CFTRY> block, I have it use the 'APPLICATION.coms.fw.error' component to handle processing of that error.

 

This is all well and fine, but during the first call to the application, where everything is starting up, lots of processing is done reading configuration files to get pathing, etc.  And that code has <CFTRY> blocks, but the thing is, they wouldn't be able to all the error component (because it hasn't yet been instantiated).

 

So should I just do something like:

 

<cfif isDefined( 'APPLICATION.coms.fw.error' )>
<!--- Handle Error Via Component. --->
<cfelse>
<!--- Output message to screen, use CFLOG to log error and the CFABORT to halt further processing. --->
</cfif>
 
Replies
  • Currently Being Moderated
    Mar 23, 2013 12:18 AM   in reply to Aegis Kleais

    Hi Aegis Kleais,

     

    "And that code has <CFTRY> blocks, but the thing is, they wouldn't be able to all the error component (because it hasn't yet been instantiated)"

     

    -- What if if you use only try catch to handle it. I am not sure about the purpose of using "APPLICATION.coms.fw.error" but it seems that you can try simple try catch to handle it.

     

    <cftry>

    //your code here

    <cfcatch type="any">

    </cfcatch>

    </cftry>

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 23, 2013 1:18 AM   in reply to Aegis Kleais
     
    |
    Mark as:
  • Currently Being Moderated
    Mar 23, 2013 10:56 AM   in reply to Aegis Kleais

    Aegis Kleais wrote:

     

    I read the entire article and it goes into basic tools that ColdFusion has for handling errors (CFTRY/CFCATCH) using the onError() method in the application.cfc, etc.  But it doesn't seem to address the issue I'm having.

    If your requirement falls outside those standard error-handling methods, then it is very likely that the requirement involves some over-designing.

     

    The APPLICATION.coms.fw.error is a component that has been instantiated into the APPLICATION scope (so that it is available to all user across the application)

    It is unclear to me whether APPLICATION.coms.fw.error is an application variable (in which you've stored an instance of a CFC created, for example, using createObject) or the path to error.cfc in dotted notation(that is, the path /application/coms/fw/error.cfc).

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 24, 2013 1:58 AM   in reply to Aegis Kleais

    Aegis Kleais wrote:

     

    I basically just didn't want to have to place code that checked if these CFC's existed each time I did a CFTRY/CFCATCH (because there is error-handling done before those CFC's are put into the APPLICATION scope)

    That answers your question! Instantiate the CFC and store the instance in the application scope just before this particular error-handling. You will then know, in all the code that follows, that the application variable exists.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 24, 2013 2:11 PM   in reply to Aegis Kleais

    As a rule, you should avoid any elaborate code logic, such as if-then-else, in the pseudo-constructor area. In fact, I think the design is only getting more complex.

     

    Originally, you wished to ensure a variable in the application scope exists, before you could do something else. My suggestion was, why not set the application variable right at the beginning. As you have now revealed, onApplicationStart is the ideal place to initialize the application variables. Such variables will then be available anywhere in the application, and throughout the life of the application. Voila! Original question answered.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 24, 2013 2:15 PM   in reply to Aegis Kleais

    Get rid of any logic like that. Initialise your application in onApplicationStart. There. Done. It's initialised. No need to do tests like "is it initialised?", because you know the answer will be yes.

     

    Limit any logic in the pseudo consrtuctor to that dealing with this-scoped variables. Don't mess with variables of any other scope in there, because it's the wrong place to do it. Set application-scoped variables in onApplicationStart(), session ones in onSessionStart(), and request ones in onRequestStart(). They're there for a reason.

     

    Also perhaps read this:

    http://adamcameroncoldfusion.blogspot.co.nz/2012/08/more-on-applicatio ncfc-when-things-run.html

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 24, 2013 3:06 PM   in reply to Aegis Kleais

    Aegis Kleais wrote:

     

    Don't the THIS-scope ColdFusion Application variables have to be set in the constructor area of the application.cfc?

     

     

    Well... yes. Which is what I said.

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 25, 2013 11:34 AM   in reply to Aegis Kleais

    Aegis Kleais wrote:

     

    I was confused because I saw BKBK's comment that stated "As a rule, you should avoid any elaborate code logic, such as if-then-else, in the pseudo-constructor area."

     

    Maybe he meant it's more of a "guideline" than a hard rule?

    By 'rule' I of course meant guideline. It is clear from the example.

     

    Well, then, knowing that I have applications with configuration XML files that are loaded up and can specify the application's unique CF application variables, wouldn't it be OK for me to have out-of-onApplicationStart() code in my constructor that checks if the application exists or not, and if so, creates those THIS-scope vars each time the application.cfc is called?

    You're perhaps confusing application-scope variables with application.cfc's public instance variables. Application-scoped variables are of the form application.someVar, and are usually initialized in onApplicationStart. They apply to the entire application, and so can be referenced directly in any ColdFusion page or CFC.

     

    Application.cfc's public instance variables are usually of the form this.someVar, and are set in Application.cfc's pseudo-constructor area. They apply to just Application.cfc. You cannot reference them directly in a ColdFusion page or CFC.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 25, 2013 11:57 AM   in reply to Aegis Kleais

    Aegis Kleais wrote:

     

    Would that mean that in the APPLICATION.CFC's pseudo constructor, that the THIS-scope and VARIABLES-scope are the same thing?

    No. This.someVar is public, wheres variables.someVar is private.

     

     

    As you stated, I have APPLICATION-scoped variables stored in locations like 'APPLICATION.variablename' as well as more detailed structures under the APPLICATION scope like 'APPLICATION.coms.fw' (which holds all framework components).

     

    I am finding that in my onApplicationStart(), any VARIABLES-scoped variables that I have has to be provided along with the call to components in order for them to have access to that value (without going through component extension)

    The way to go is, application-scoped - not variables-scoped - variables, defined in onApplicationStart().

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 26, 2013 1:21 PM   in reply to Aegis Kleais

    Over and above the scope accessibility thing, in Application.cfc, the only real reason to use this-scoped variables are to set the predefined application settings (eg: this.name, this.sessionManagement etc). And variables-scoped variables would simply be for the reason one might usually have variables-scoped variables within a CFC.  At the end of the day Application.cfc is still just a CFC, so all the scoping and usage rules are the same. Except that some this-scoped variables have special meaning as far as the application framework is concerned.

     

    --

    Adam

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points