User Guide

308 Chapter 14: Handling Errors
• Use the cferror tag to specify ColdFusion pages to handle specific types of errors.
• Use the cftry, cfcatch, cfthrow, and cfrethrow tags to catch and handle exception errors
directly on the page where they occur.
• In CFScript, use the try and catch statements to handle exceptions.
• Use the onError event in Application.cfc to handle exception errors that are not handled by
try/catch code on the application pages.
• Log errors. ColdFusion logs certain errors by default. You can use the cflog tag to log other
errors.
The remaining sections in this chapter provide the following information:
• The basic building blocks for understating types of ColdFusion errors and how ColdFusion
handles them
• How to use the cferror tag to specify error-handling pages
• How to log errors
• How to handle ColdFusion exceptions
Note: This chapter discusses using the cftry and cfcatch tags, but not the equivalent CFScript try
and
catch statements. The general discussion of exception handling in this chapter applies to tags
and CFScript statements. However, the code that you use and the information available in CFScript
differs from those in the tags. For more information on handling exceptions in CFScript, see
Chapter 9, “Handling errors in UDFs,” on page 186.
Understanding errors
There are many ways to look at errors; for example, you can look at errors by their causes. You can
also look at them by their effects, particularly by whether your application can recover from them.
You can also look at them the way ColdFusion does. The following sections discuss these ways of
looking at errors.
About error causes and recovery
Errors can have many causes. Depending on the cause, the error might be recoverable. A
recoverable error is one for which your application can identify the error cause and take action on
the problem. Some errors, such as time-out errors, might be recoverable without indicating to the
user that an error was encountered. An error for which a requested application page does not exist
is not recoverable, and the application can only display an error message.
Errors such as validation errors, for which the application cannot continue processing the request,
but can provide an error-specific response, can also be considered recoverable. For example, an
error that occurs when a user enters text where a number is required can be considered
recoverable, because the application can recognize the error and redisplay the data field with a
message providing information about the error’s cause and telling the user to reenter the data.
Some types of errors might be recoverable in some, but not all circumstances. For example, your
application can retry a request following a time-out error, but it must also be prepared for the case
where the request always times out.