Dave's advice is right on the money Richard. You want to have layers in place where the site-wide handler is the last line of defense, the CFERROR/onerror handles the everyday stuff and try/catch is reserved exclusively for known issues where you can introduce a tailored recovery or notification.
What you do about the errors once they are thrown is very important of course. When it comes to just having the error diagnosed (used for the site-wide and application-level handlers) I have found that a comprehensive dump of all in-memory variable scopes is the key to finding your cause and fixing it. In particular the error scope (or the cfcatch scope if you're in a try/catch block) contains a struct within it that is an execution trace that will tell you exactly which template on what line caused an error. If you are calling a file that calls an include that calls a custom tag that then throws an error you don't want the generic error message that is tied to the calling template. You want to follow the trace thats located in the error (or cfcatch) scope and use THAT reported template and line number. The trace will let you follow the line numbers from one template to another so you will know exactly what called what and where. Absolutely invaluable to the debugging process. For more info check this out: http://mysecretbase.com/Building_A_ColdFusion_Error_Handler.cfm Describes a site-wide error handler but the dump builder is a good candidate for a custom tag that you can use for all sorts of things. It can be easily adapted to a cferror function as well. What you do with the errors is at least as important as capturing them in the first place. With error dumps like the above, which can get mighty big, emailing the whole dump can be impractical. Also bear in mind you are dumping memory contents and this has serious security implications. For an application-level handler I like to dump to a database, where a dedicated table contains fields for date/time, errored template, referrer and the basic basic CF error message. I display this in an admin area via a simple GridMonger grid. If I need to see the full dump a link goes to that dump... which was NOT stored in a db but rather was stored on disk in a .html file, which in turn sits in a protected folder. I like storing to disk as, if your db is bad then so is your error reporting. -- [EMAIL PROTECTED] Janitor, MSB Web Systems mysecretbase.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:255059 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
