Skip to main content
P
PHRED-SE
Inspiring
March 29, 2010
Question

Conditional use of <cftry> ... <cfcatch>

  • March 29, 2010
  • 1 reply
  • 1955 views

I have been using the <cftry>…<cfcatch> methodology for over 5 years.  It generally works very well.  When there is a case where we need to trap an error and put out a friendly error message that works well also. When we need to know the actual problem, we have been commenting out the <cftry> … <cfcatch> mechanism and letting the CF detailed error message appear on the page.  Since we are working on a test server, it doesn’t hurt anything to have the CF Robust error capability turned on.  One would never do this on a production server, however.

We have recently decided that we do not want to continue to comment out these items because then the file dates get out of wack with the comment/note dates. There is a big push on, and rightly so, to keep these in synch so that we will know if folks are forgetting to note their changes at the top of the file.

So it occurred to me that if I could surround the <cftry> and <cfactch> with <cfif> statements, then I could make this a conditional thing and enable (include) and disable (hide) them at run-time by changing the setting of a Session varable.

Here is a simplified version of what I tried.  I would set Session.UserRobustErrMsgs to false or true depending upon what I wanted the system to do.  Normally is we be set to False: do not use robust error messages.

<cfif #Session.UseRobustErrMsgs# Is False>

      <cftry>

</cfif>

      Do something here….

<cfif #Session.UseRobustErrMsgs# Is False>

      <cfcatch>

            Do friendly error message here>

      </cfcatch>

      </cftry>    

</cfif>

Note that there is nothing between the </cfcatch> and the </cftry>.

While it might have been a good idea, CF didn’t like it. CF threw the following error message:

The start tag must have a matching end tag.  This could be because

<cfcatch> is not the last tag nested in the <cftry>.  <cfcatch> must

Be the last tag insde a <cftry> tag.

If anyone knows of a conditional <cftry> … <cfcatch> technique/methodology, I would appreciate your shaping it with me.

Thank you in advance for your help.

:-}

Len

This topic has been closed for replies.

1 reply

ilssac
ilssac
Inspiring
March 29, 2010

Don't try to be conditional about the whole try/catch block... be conditional about the catch message.

I.E.

<cfcatch...>

    <cfif this EQ that>

      DO friendly error message here

    <cfelse>

      DO developer informative message here.

      <cfdump var="#cfcatch#"> is easy.

    </cfif>

</cfcatch>

Of course I would also be loging or emailing the real cfcatch data for developers anyway, even when the friendly message is displayed.  It is usually nice to know when my software is handling exceptions.

P
PHRED-SEAuthor
Inspiring
March 30, 2010

Ian,

     Thanks.  That turned out to be almost the perfect answser.

     I didn't like all that stack stuff since I have now idea what it all means so I changed it so that I only add the "cfcatch.cause.tagcontext" after my normal friendly error message and it give me everything I need to figure out where the error is.  I will not have to add the session var since they will always get this error message.

     <tr><td height="75" align="center" valign="middle"><img src="../Images/#sLogoName#"></td></tr>
                <tr>
                    <td class="daWarning">
                    <cfif #Len(cfcatch.message)# gt 0>
                        #cfcatch.message#<br>
                        #cfcatch.detail#<br><br>
                    <cfelse>
                        An Unknown Error has occurred.<br>
                    </cfif>
                    </td>
                </tr>
                <tr>
                    <td class="daWarning">
                        <cfdump var="#cfcatch.cause.tagcontext#">
                    </td>
                </tr>
                <tr>
                    <td align="center">
                        <br>
                        <INPUT TYPE=BUTTON VALUE="Go back..." onClick="history.back();">
                    </td>
                </tr>

     Here is what it looks like. You get the file name as well as the line number which is all you need in additon to the message to find the cause.

     Thanks for your help once again.

:-}}}

Len

ilssac
ilssac
Inspiring
March 30, 2010

I would be very cautious to displaying that type of raw information to users.

If you don't have a really good idea of who exactly your users are, that information you are displaying could be very valuable for hackers.  Hackers just love causing errors on sites that don't suppress exception output and finding out tons of useful information about the systems behind the web interface.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices