Error Handling
While the best efforts are made to stop errors from happening, they do happen. Sometimes the errors might be due to some bad code; other times it may be due to external resources that are out of one's control. During the development process, these errors hold valuable information that allows us to improve and fix our code, but in production environments, these errors hold information that can make our servers vulnerable to attack. It is important that as a developer you anticipate errors and gracefully handle them. Thankfully, ColdFusion offers a number of ways to trap those errors and even allow developers to react to those errors and call alternative functionality.
Understanding Errors Error Types Before we look at how to handle the errors, lets first take a look at the errors themselves. There are three types of ColdFusion Errors: • Exception - Where the error stops the request from completing its process. • Missing Template - When an HTTP request for a page can not be found. • Form Field Data Validation - When server side form validation fail. The most common error type you are going to experience is the Exception type. Unless the users are requesting a page that does not exist, or you have decided to use ColdFusions in-built form validation (not recommended by most ColdFusion developers), you will receive an Exception error. These exception errors, excluding custom errors, fall into one of the following exception types: • Database - When there is a problem with a database cal,l such as malformed SQL or database connection issue. • MissingInclude - When an included file can not be found. • Template - When a general error occurs, usually from a malformed tag or incorrect script syntax. • Object - When an error occurs with an object. • Security - When an error occurs related to security functionality. • Expression - When an expression fails, such as 1 + "a". • Lock - When an error occurs with a piece of code that has been locked by the application. This can be due to the code failing at runtime or a lock timing out. • SearchEngine - When there is an issue with the Verity Search Engine. • Application - When custom errors are generated by the cfthrow tag that do not have a type defined. Knowing the type of exception thrown can be useful when handling your errors gracefully. Depending on the type of exception, it might be possible to retry a section of code again. For example, if a section of code that communicates with an external service times out, you might want to try again to see if the second time is successful. If you try this approach with some errors, it is important to keep in mind that your request might never be successful and that the error must then be handled a different way. Learn CF in a Week - Week 1 - Error Handling and Debugging
Page 272