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

[PHRED-SE]

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

[ilssac]

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.

[PHRED-SE]

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]

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.

[PHRED-SE]

Ian,

     We just spent the last 3 months getting all of our SQL Injection and XSS stuff sorted out.  We discussed this very thing this morning and decided that there was nothing here that would present a real issue.  We thought that since there was no database info being shown, that it would not hurt anything if they could see the file name and path....

     Since this is not our expertise, perhaps we were being nieve.

:-}

Len

[ilssac]

PHRED-SE wrote:

     Since this is not our expertise, perhaps we were being nieve.

:-}

Len

Yeah, a little.  While SQL injection and XSS are the most prevelant threats, they are not the only ones.

There is another level where hackers use tricks and volnerabilities to load up their own code (cfml for your ColdFusion server) files to the website.  Through froms and what not.  Then, if they can get the server to execute these files they can gain control of it.  Having the file path of where the server executes files from is quite helpful in this type of attack.

[PHRED-SE]

Ian,

We had just finished our discussion about this whole thing and had decided that we live in a very dangerous world and that it would be better to error on the side of caution.  Consequently, we had decided to put the <cfif> in as you suggested so that the full error will only be shown when we enabled it for diagnostic purposes.

Your follow-up email told us what we didn't know -- Why.

Thanks again for all your help on this and many other things.

:-}

Len