> I must admit that I'm quite confused now as I've had myErrorHandler.cfm > email me with details of errors for (literally) years. For example if I > generate an error by referencing an undefined variable (eg <cfset newvar = > a_var_that_does_not_exist> ) then everything works just fine I get emailed > details of the error and the user gets a pretty page saying sorry. How come > <cfoutput>#</cfoutput> makes my error handing process stop working in this > way yet <cfset newvar = a_var_that_does_not_exist> is fine?? > > Looking at the bigger picture, surely I can't be the only one who wants CF > to email them with the details of any errors that occur (without requiring > the user to generate that email to me themselves) and also to show the user > a professional looking (and secure ie no code shown) error message - what > does everyone else do to achieve this? > > Any further thoughts from anyone would be very much appreciated.
Well, there's a particular bit of information that we're glossing over here. When you run a CF page for the first time, CF first has to compile the page, then run it. If the CF page has a typo or completely invalid statement, that will prevent it from compiling. Unless you're dynamically generating CFML, that shouldn't be an issue in production, only in development, and therefore you shouldn't need an error handler for that - if you do, that indicates that you're not even running your page once before placing it in production! If the page compiles successfully, but doesn't have the inputs it needs or if those inputs aren't valid, or if the page can't access some resource it needs, that causes a run-time exception. Those are the kinds of problems you have to worry about in a production environment, because they can be caused by lots of things that you can't predict ahead of time. When you use CFERROR with TYPE="REQUEST", that catches both run-time exceptions (which you care about) and compile-time errors (which you don't). This is the oldest error handling mechanism in CF, and the most limited. Presumably, when it was introduced (CF 2 or earlier, I think - I'm not exactly sure) the developers at Allaire didn't know how to have their error handler fail without generating an infinite loop, or it was too difficult or expensive to build it that way. The TYPE="VALIDATE" error handler works the same way, presumably because it shares some common functionality (it's also very old, introduced at the same time). But again, honestly, you generally shouldn't be interested in catching compile-time errors, because they shouldn't exist in production. If they might, they can be caught by the site-wide error handler, which catches anything except validation errors. All of the stuff you want to do, though, can be done with exception handling either in your page directly, or with the onError event handler, or with CFERROR using TYPE="EXCEPTION". Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:339894 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
