One of the great new features in 4.5 is a new form of global exception handling. Whereas 4.0 introduced CFTRY/CFCATCH to wrap around a segment of code to be tested and acted upon in case of error, we were still limited to the aged CFERROR tag to trap general errors.
The benefit of CFERROR is that you get to create a page with the layout and background colors to suit you and your organization's preferences, rather than the unadorned white page with black text that is normally displayed when a CF error is encountered.
Unfortunately, until 4.5, you could only use HTML on this error handling page. No CFML. There was a presumed CFOUTPUT open, but the only available variables were those holding information about the error.
You couldn't trigger an e-mail with CFMAIL, nor could you log the error in a database. These limitations kept many from bothering, which is too bad because end users were stuck with the simple "spit-up" on the screen that's normally shown with CF errors.
Now, in 4.5, there is a new option for CFERROR, called TYPE=EXCEPTION, which allows you to specify an error page to handle processing of otherwise untrapped errors. It directs control to the named page and that page is allowed to do full CF processing, unlike the older CFERROR TYPE=REQUEST.
New Site-Wide Error Handler
Also, in 4.5, there is a new option to specify (in the CF Administrator) a site-wide error handling template. Think of this as handling errors when the CFERROR mentioned above is not used. It takes the user to the specified page which, again, has full access to CF processing, including creating e-mail with CFMAIL, creating a log file in a database, and more.
Charlie Arehart
Allaire Certified Trainer
Course Developer
Fig Leaf Software