Close Window

Print Story

Errors in Your Code

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.


Debugging: Resolving Errors
When it comes to resolving errors, there are a variety of tags and techniques to assist you. Some are features to help you while running a request to provide additional information to track the program's state, while another is the ability to do interactive step debugging, and the last are related to getting system diagnostics. We don't have room to elaborate on these, but do be aware of them.

Additional Info To Track Program State
The first set of debugging tools, some of which are widely used while others are still a surprise to many, are the debugging info enabled in the Admin console, CFDUMP, CFLOG, CFTRACE, CFTIMER, and the cfstat command-line utility (BlueDragon doesn't currently support the last two). Even CFOUTPUT and CFABORT can be useful techniques when debugging. These topics have been covered in more depth in the following articles (and of course, the documentation):

There is also a new article this month related to the above: "Faster debugging with CFTIMER and CFTRACE", by Shlomy Gantz.

I'd also like to point out that BlueDragon offers a useful tag called CFDEBUGGER to supplement those above. It traces all the lines of CFML code executed in a given request, something that CF developers have never had. I wrote about it in a past CFDJ article: CFDEBUGGER (November 2003) http://coldfusion.sys-con.com/read/42101.htm.

Interactive Step Debugging
Of course, when some think of debugging they immediately think of interactive "step" debugging, and those folks have long complained that CFML lacked such a capability (while some others don't miss it at all). As we went to press, the folks at Fusion-Reactor.com (Intergral GMBC) released their FusionDebug tool, which is an Eclipse plug-in that finally provides step debugging for ColdFusion MX. Learn more at www.fusion-reactor.com/fusiondebug. It's something I'm excited about. While many never knew it, we did indeed have debugging available in ColdFusion 5 and before by way of ColdFusion Studio (or today's HomeSite+). I've mentioned it in, "Browsing within CF Studio/HomeSite+" (August 2003) http://coldfusion.sys-con.com/read/42061.htm. I even walked folks through using it in a 1999 presentation, available at www.systemanage.com/presentations/debugger-setup.pdf. One reason I never wrote about it here is that it didn't always work. Still, I'll point out that the official documentation, which many never knew existed, was in Chapter 9 of Using ColdFusion 5 Studio at http://livedocs.macromedia.com/coldfusion/5.0/Using_ColdFusion_Studio/debug.htm. It should be possible to get it working with CF Studio and/or HomeSite+ with ColdFusion 5, if you still have them both.

System Diagnostics
Of course, sometimes to understand error situations you need more information than just what's reflected in running the current page. There could be other activities or problems in the environment that are impacting your code. When it comes to gathering diagnostics to understand and resolve problems, you should consider taking advantage of the built-in logs, available in the aforementioned ColdFusion logs directory. There's also an interface to view them in the Admin console.

Beyond that, though, there's even more powerful analysis of what's going on in your environment available by way of two commercial (yet reasonably priced) tools that have come out in the past year or so: SeeFusion at www.seefusion.com and FusionReactor at www.fusion-reactor.com. Both are available on a free trial basis so check them out.

There may be problems that are outside of ColdFusion that are affecting you. Be sure to consider analyzing your Web server, database, network, and the operating environment of the machine running ColdFusion. There are logs and analysis tools for each that are beyond the scope of this article. Finally, another vital tool when solving problems in CFML is simply knowing what you should and shouldn't be doing in CFML. Don't forget that you have documentation available at livedocs.macromedia.com (no, the domain name hasn't changed yet). And more than just the CFML reference, there's a 900+ page Developer Guide and more.

Testing: Preventing Errors in the First Place
While it's admirable to do a better job catching, handling, and debugging errors when they occur, shouldn't we try to prevent them in the first place? There are several ways you may be able to test your code to prevent errors occurring at all, as we will discuss, ranging from unit testing to syntax checking to validating your page input and output.

Unit Testing
To prevent bad code from getting into production many would recommend doing better unit testing, a subject within the broader topic of test-driven development. CFML offers various implementations of such unit-testing tools ranging from test harnesses to cfunit and cfcunit, as discussed in:

Note that cfunit used to be part of the Developer Resource Kit (DRK) but it's now available at the site above. There are still other forms of testing to keep in mind.

CFML Syntax Checking
Since CFML isn/t a compiled language, many errors slip by because we don't need to "run a compile step" before releasing our code into the wild. We may have syntax errors that would cause a page to fail as soon as it's run. How can we catch them without actually running every page? Again, good unit tests would help, but until you implement them, there's still another approach.

Did you know that there are various means to check your CFML code's syntax before releasing it? Since release 4, the Admin console has had a mechanism that lets you point to a directory of code. It will analyze your CFML and report if there are problems. While in CFMX it's formally called a Code Compatibility Analyzer, with a focus on checking code from previous releases, it also does CFML syntax checking (see the "Advanced Options"). There has also been one in CF 4 and 5. Note that you can point it at an entire directory (and optionally recurse into subdirectories), so it's definitely something to consider as a regular part of testing. See the online help in the Admin console for more information.

Perhaps you're perturbed that that tool is a Web interface requiring you to enter data in a form. You want a command-line tool. I'm not aware of a means to call that compatibility analyzer from the command line, but did you know that CFMX 6.1 added a command-line precompile tool? It's in the /bin directory as cfcompile.bat. While the primary purpose is performance improvement (saving the auto-compile that takes place on first load of the page into server memory), it will report if there are any errors during evaluation of the CFML, so it can act very much like the missing compilation step that other developers use to catch errors early. Again, it is a command-line tool, and it does by default compile all templates in a given directory.

See Chapter 5 of the CFMX 7 Administration manual (but not in the CFMX 6.1 manual) for more information. It's also discussed in the following article. Though the focus is on J2EE Web application deployment, the discussions of cfcompile are still broadly useful: "Deploying Applications with ColdFusion MX 7" (Dave Carabetta, March 2005) http://coldfusion.sys-con.com/read/48654.htm.

I'd like to point out also that I had discussed the benefits of such a precompile tool in a two-part series. Though it was written before the tool was released officially in 6.1, some of the info may still benefit:

Input and Security Validation
Still another form of testing to consider before you turn your application out for production implementation is a range of tests that focus on ensuring that the application avoids errors by preventing inappropriate input or cross-site scripting as discussed in: Output Validation
Other forms of testing focus on the output of your pages such as validating your HTML code (accessibility checking, CSS validation, link checking, and spell checking) as well as regression, load, and concurrency testing. I covered all of these in "E-Testing: Debugging Your Projects" (October 2001) http://coldfusion.sys-con.com/read/41816.htm.

Other Error-Related Topics
There are still other topics that are tangentially (or perhaps directly) related to error handling, including handling errors from CFMAIL, using the CFTHROW tag, doing site monitoring, load testing, and leveraging version control to manage your code better and recover from erroneous code releases. Again, there's no room to elaborate, but I'll point out one more article that covers a range of topics including error handling, testing, and source control: "7 Habits of Highly Effective ColdFusion Developers" (Robi Sen, February 2004) http://coldfusion.sys-con.com/read/43534.htm.

And while I'm mentioning error-handling articles, some will get value out of a past article on handling errors in JavaScript: "Error Handling in JavaScript" (Steve Bryan, October 2002) http://coldfusion.sys-con.com/read/41671.htm.

Finally, I'll also point out that in this month's issue there is an article from Joshua Curtiss on yet another error-handling concept, "Handling 404 Errors for a Migrated Blog".

I hope this trip through the archives of the CFDJ focusing on error handling, debugging, and testing will help improve the quality of your CFML development.

© 2008 SYS-CON Media Inc.