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:

• "Toward Better Error Handling - Part 1 (Admin Settings)" (October 2000) http://coldfusion.sys-con.com/read/41977.htm
• "Toward Better Error Handling - Part 2 (Error Handling Templates)" (November 2000) http://coldfusion.sys-con.com/read/41844.htm
• "Toward Better Error Handling - Part 3 (Application-Level Error Handling)" (January 2001) http://coldfusion.sys-con.com/read/41870.htm
• "Toward Better Error Handling - Part 4 (Page-Level Error Handling)" (June 2001) http://coldfusion.sys-con.com/read/41772.htm

• "Expect The Unexpected" (October, 1999) http://coldfusion.sys-con.com/read/41494.htm
• "To Err Is Human, to Gracefully Handle Errors Is Divine" (March 2002) http://coldfusion.sys-con.com/read/41727.htm

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.