Print Article          Return         

CF Error Handling - A pinch of this, a pinch of that
By: Al DiMarzio, HB Graphics
Guilford, CT

I received a call from a client the other day informing me that his on-the-floor Internet-based Customer Kiosk had generated another CF error message. This has been ongoing for about six months with perhaps one or two error messages a week. The code of course, had been examined rigorously, but perhaps it was time for some generalized CF error handling. An additional suspect was the wireless communications link. (The first lesson a software developer learns is to blame the hardware). Yet a third suspect was XHML processing to/from a third-party web site. (The problem was later discovered to be the wireless link that would drop the connection).

The problem solving approach had to accomplish two things: send useful debugging information to the developer, and provide a graceful recovery for the user. Looking at the code I selected two options: use the <cftry><cfcatch> tags or use the <cferror> tag. After a few experiments I selected the <cferror> tag combined with some HTML form coding and a little javascript code ... a pinch of this, and a pinch of that.

The CF errors appeared to be generated from different .cfm pages. The commonality between the errors being that they were all variables passed from one of several form pages to a processing page ... "Error resolving parameter WXYZ". I checked all the front, back and side doors to the processing pages and found that all variables were accommodated, either within the <form> tags, or by a <cfparam> tag. Somewhere along the line things were getting lost … but how to find out where?

<cftry><cfcatch> tags approach

On the first pass I headed for the most versatile approach: the <cftry><cfcatch> tags. Using these, I can surround my application code with the <cftry> tags (what is "trying" to happen), and place the what-to-do-if-there-is-an-error code between the <cfcatch> tags (where we "catch" the error). Sounded easy to me so I took the following generalized approach:
    <cftry>
         [application code here]
    <cfcatch type="any">
         [ask user to try again]
         [send email to myself about problem]
    </cfcatch>
    </cftry>
I like to write modular code, so putting the error trapping code in <cfincludes>, made a lot of sense. One of my dog-eared CF books mentioned this approach. I can add a "error_header.cfm" at the top of each page and an "error_footer.cfm" at the bottom. Problem solved!

Errrr, the <cfinclude> approach did not work. Upon checking with Macromedia's CF Forum I found that <cftry> and <cfcatch>, and perhaps other CF tags, need to be on the same page as the application code to work correctly. I had too many pages to fiddle with so I scratched this approach.

The <cferror> tag approach

The next approach was to use the <cferror type="Request" template="error_kicker.cfm"> tag until I read that you cannot use CF tags inside the referenced template file. That is, the "error_kicker.cfm" page would have to be completely non-CF code. Since I wanted to retain the site-standard system of header, footer, menu <cfinclude>s this would mean duplicating code and the error section becoming non-modular.

At about this time a light bulb illuminated above my balding head, albeit dimly … use a combination of HTML form and javascript coding on the page referenced by the <cferror> tag. The referenced page would then send the parameters to a second page which would process the email and provide recovery for a user.

There are many ways to solve this kind of a problem, however here is the approach I implemented.
  • Instantiate the <cferror> tag in the Application.cfm page
  • Create a pure HTML/JavaScript page which is referenced by the <cferror> tag
  • Create a second page to receive the error information and handle user recovery
The Application.cfm page

In the Application.cfm page I inserted the <cferror> tag code which looks like:

     <cferror type="Request" template="error_kicker.cfm">

When an error occurs, the following information is available to the page referenced by the "template", I.e. the "error_kicker.cfm" page.
  • Browser: the browser the user was running, etc.
  • Diagnostics: detailed diagnostic message returned by the CF server
  • HTTPReferer: URL of the page where the error occurred
  • QueryString: the URL's query string, if any
  • DateTime: the date and time the error occurred
  • RemoteAddress: the IP address of the user
  • Template: template being processed when the error occurred
The scope of these variables is "error" and they would be referenced in a manner such as #error.Browser#.

The referenced template page

While the <cferror> tag has a lot going for it, the little extra coding and a second page provide a very professional look to the system. But most of all, the second page allows for a user friendly recovery where I can use all my header, menu and footer includes, maintaining the modular system design.

Putting the error information into an HTML form looks like the following:
    <!--- error_kicker.cfm page ---> <html>
    <head>
    <title></title>
    </head>
    <body>

    <!--- Use an HTML form to preserve and pass error information --->
    <form Name="kicker" action="error_handler.cfm" method="post">
    <input type="hidden" name="Browser" value="#error.Browser#">
    <input type="hidden" name="Diagnostics" value="#error.Diagnostics#">
    <input type="hidden" name="HTTPReferer" value="#error.HTTPReferer#">
    <input type="hidden" name="QueryString" value="#error.QueryString#">
    <input type="hidden" name="DateTime" value="#error.DateTime#">
    <input type="hidden" name="RemoteAddress" value="#error.RemoteAddress#">
    <input type="hidden" name="Template" value="#error.Template#">
    </form>
Now to automatically send the form on to the next page we use a little JavaScript: "submit()" function. "kicker" is the name of the form and must be referenced in the document statement of the JavaScript.

    <script Language="JavaScript">
    <!--
    document.kicker.submit()
    // -->
    </script>

    </body>
    </html>
 The error handler page

Nothing magical here. This page simply receives the HTML form information and attempts a graceful recovery. The code looks something like the following:

Starting with the usual web page which conforms to the rest of the site.

    <html>
    <head>
    <title>WXYZ Company</title>
    <link rel=stylesheet type="text/css" href="scripts/wxyz.css">
    </head>
    <body>

    <div align="center">
    <img src="images/header_ooops.jpg" width="600" height="73" alt="" border="0>
    <cfinclude template="insert_topmenu.cfm">
 We first provide information to the user that an error has occurred and request they attempt to enter the information a second time.

    <!--- Attempting a graceful and friendly recovery --->
    <table width="550" border="0" cellpadding="0" cellspacing="0">
    <tr>
      <td class="bodytext">
      We are sorry to report <b>there has been a system error</b> and any information<br>
      you have entered into the forms has been lost.<br>
      <br>
      We regret your inconvenience and would <b>appreciate it if you would try again</b>.<br>
      <br>
      Should you get this message a second time, please contact a store manager.<br>
      <br>
      <b>Thank you</b> and have a fine day at WXYZ's.<br>
      <br>
      </td></tr>
    </table>

    </div>
 Lastly we send the developer the cherished error information. The #form.Diagnostics# from Cold fusion is in an HTML format and so I found it desirable to encapsulate it as an HTML page to make it easier to read in my email client.

    <!--- Sending the information to the developer/IS --->
    <cfmail
    to="someone@developer.com"
    from="error@wxyz.com"
    Subject="Error message from Kiosk">

    Browser: #form.Browser#
    Date/Time: #form.DateTime#
    Diagnostics:
    <html><body>
    #form.Diagnostics#
    </body></html>
    Referer: #form.HTTPReferer#
    Query String: #form.QueryString#
    Remote Address: #form.RemoteAddress#
    Template; #form.Template#
    </cfmail>

    </body>
    </html>
 In summary

Seven years ago when many of us were programming mostly in HTML, code and web design was simple. But technology waits for no one. So in today's applications we use multiple languages, Java applets and various aides to create a variety of web sites and solve problems. Like Chefs seasoning food, developers have their "spices" to judiciously sprinkle on applications ... a pinch of this, and a pinch of that makes a robust application.

About the Author

For additional information about the author, please select Author Biography.

Print Article          Return         

I job core This website about wal mart jobs As to work from home jobs For travel nurse job This website has information on summer jobs Purchase nursing job This is nurse jobs You search here hrdc job bank Whith jobs online