The World's Favorite Open Source GPL J2EE CFML Runtime Engine

BlueDragon Developer's Journal

Subscribe to BlueDragon Developer's Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get BlueDragon Developer's Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Open BlueDragon Authors: Reuven Cohen, Elizabeth White, Michael Sheehan, John Gauntt, Salvatore Genovese

Related Topics: Open BlueDragon Developer's Journal, ColdFusion on Ulitzer, Java EE Journal

BlueDragon: Article

Errors in Your Code

Handling, debugging, and testing for them

Errors and bugs: they happen in all code, mostly in development but in production too and perhaps more easily in CFML than in compiled languages. There are several features to help better handle, debug, and test for them, and this article will focus on those.

I started writing in the CFDJ in 1999, and I often point people back to my previous articles and those of others when challenges arise. The most common one I point to is my 4-part series on error handling from five years ago, and still other authors have addressed related but different aspects. It seems the issues of dealing with, resolving, and testing for errors remain important.

In this article I'll revisit the coding techniques and configuration settings available to improve error handling, as well as approaches to help debug and resolve errors when they occur. Some may surprise you. I'll also discuss testing techniques to help alleviate the likelihood of errors occurring in the first place. I'll end with a few other error-related topics that might often miss attention, and along the way I'll point you to those past articles and other resources to get you started. (Unless otherwise indicated, all the features discussed here apply to BlueDragon as well as ColdFusion 5 and MX.)

Gracefully Handling Errors
We're all going to have errors as we're coding. It's one thing to deal with an error when it arises during development. You see the error and go back into the code to fix it then re-run it. Actually, you may need some help in determining the cause of the error, and I'll talk about that in the section on debugging. But it's quite a separate (and often ignored) problem of dealing with errors that occur when your code is running in production. Does the user get the traditional - admittedly Spartan - default error message that ColdFusion generates? And are you careful about what details they are shown (as can be controlled in the Admin console)? Or better still do you "handle" the error more gracefully? If you don't know how to do these, this section will help get you started.

As the CFML language has evolved, there have been various features offered to help you handle errors. This variety of alternatives can sometimes confuse newcomers, and even experienced developers. It's important to remember that CFML is now over 10-years-old, and some tags or features have been superseded by other more powerful approaches. Each of the following topics is covered in more detail in the articles and documentation references that I'll offer throughout this article.

Error Handling Approaches
THE TAGS AND FEATURES
CFERROR type="request"
CFERROR type="exception"
Sitewide error handlers
Controlling exception information
CFTRY/CFCATCH
Try/catch
CFRETHROW
onError() in Application.cfc

The first tag introduced to help with error handling was the CFERROR tag, which names a template to be shown to the user when an error occurs. Typically defined in the application.cfm file (and so enabled for every page requested in that app), this error template would override the user seeing that basic CF error message.

When it first came out, it had only a type="request" option, and the template pointed to by this tag could not have any CFML, which made it quite limited. You could only use some HTML code to format an attractive error. There were techniques that evolved to get around that, and you may still see code that uses this tag and the type="request" option, but you really want to consider changing to the newer type="exception."

I say "newer" but it was introduced in CF4.5 (in 1999!) Sadly, many still seem to miss this feature, which brought radically new functionality. At last you could do any CFML at all in the error page, and naturally many started by adding CFINCLUDEs to reuse code to match the look-and-feel of their app or, more important, some added CFMAIL tags to finally inform the developer that an error occurred. If you still have no notification that an error is occurring this is your first stop. In the section below on "Reporting the Occurrence of Errors," I'll show even more useful approaches.

While you can provide the CFERROR in every application if you're in a situation where you have many apps and they would all have the same error handler, you can take advantage of another long-standing feature of ColdFusion. In the Admin console, you can set a "Site Wide Error Handler" (also introduced in CF 4.5), which is just a place to name a template as discussed above which can do whatever form of error handling you'd like.

Speaking of the Admin console, I mentioned previously that if you don't handle an error at all, the end user sees the default error page that ColdFusion generates. Note that there is an Admin console setting for controlling exception information, which can limit the level of detail shared. This is important from a security standpoint and is often neglected. Even if you do handle your errors, there are times when that may not work as expected and the user will get the default error message. See the resources for more information.

Older still than the two "newer" features above is the CFTRY/CFCATCH tag pair introduced in CF 4. Where CFERROR is intended to catch any error that might occur, these tags are intended to be wrapped around some set of code that you think might possibly create an error such as a database action that might fail for lack of a database connection. Again, we don't have time to go into the particulars of using this approach, but it's quite easy and discussed in detail in the references below.

Related to CFTRY/CFCATCH, there may be times when - once you've caught an error and done something with it - you may want to pass the error handling control back to whatever other error handler (a CFTRY/CFCATCH in a calling template or the CFERROR handler or Sitewide Error handler) that might do more processing. In this case, after handling the error in CFCATCH you can then use CFRETHROW to pass the error "up the chain."

These topics have been covered in previous CFDJ articles that are available online. First, I'll point out that I did a four-part series covering the topics above:

Ben Forta also wrote on error handling both before and after that series: New Features Since CFMX
All those came out before CFMX and there have been a couple more changes since then. First, in CFMX (6.0), we were given the ability to do try/catch processing in CFSCRIPT tags. Sadly, there's no corresponding rethrow statement (or a throw to match the CFTHROW tag mentioned later), but you can find a user-defined (UDF) function for the latter written by Ray Camden at the cflib.org site: www.cflib.org/udf.cfm/throw. For now, there is no rethrow UDF.

Finally and more recently CFMX 7 added the new application.cfc file to replace the older application.cfm. This has also introduced another approach to error handling in its onError() method. Nik Molnar has discussed this in his article "Macromedia ColdFusion Debugging - Don't Forget Your Bug Spray!" (September 2005) at http://coldfusion.sys-con.com/read/122162.htm.

Because BlueDragon doesn't support application.cfc yet, this is the one feature discussed so far that it can't support. Of course, all these error-handling mechanisms are covered in the ColdFusion documentation, including both the CFML Reference Manual and the Developers Guide, as well as the Administration manual, all available online at http://livedocs.macromedia.com/coldfusion/.

Reporting the Occurrence of Errors
The final topic on error handling regards the reporting of errors. Even if you do improve the quality of what the user is shown, will you even know that the error has occurred? This is a bigger problem that many applications never properly address. It's not appropriate if your user is complaining to your manager (or leaving your commercial Web site) because of an error occurring while you never knew it.

The only built-in mechanism in ColdFusion to report such errors is the application.log file available in the /logs directory where ColdFusion is installed (the /log under CF 5). Still, not many are going to monitor that closely. Additionally, it's just one file for the entire server. If you have multiple applications installed, it really won't help solve the problem of notification.

Instead, you can leverage the error-handling pages discussed above to create some form of logging on your own to track the errors. Recall the suggestion of using CFMAIL to send a notification.

Still another idea is to store the error in a log file or database record as discussed in the article "Tracking Errors: How Good Is Your Code?" (Joe Danziger, June 2003) http://coldfusion.sys-con.com/read/41618.htm.


More Stories By Charlie Arehart

A veteran ColdFusion developer since 1997, Charlie Arehart is a long-time contributor to the community and a recognized Adobe Community Expert. He's a certified Advanced CF Developer and Instructor for CF 4/5/6/7 and served as tech editor of CFDJ until 2003. Now an independent contractor (carehart.org) living in Alpharetta, GA, Charlie provides high-level troubleshooting/tuning assistance and training/mentoring for CF teams. He helps run the Online ColdFusion Meetup (coldfusionmeetup.com, an online CF user group), is a contributor to the CF8 WACK books by Ben Forta, and is frequently invited to speak at developer conferences and user groups worldwide.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.