Dusty, Something I neglected to mention is that a layered exception handling strategy will be greatly improved with giving the same level of consideration to logging. For example, I tend to log very verbosely for unattended things like scheduled tasks or gateways (things that run in a non-interactive manner). For each run I'll do opening and closing loglines with log statements for pretty much every successful and unsuccessful operation in the run. That way I have an entire trace of what happened in the event that something goes wrong, and they are easy to identify in the log files. And I always have one or more logs for every application. My preference is to not allow things to dump into the default application log, particularly in a multi-hosted setup. I don't want to dig through crap from other applications to find out what I need to know, I'd like to have it in one place. Sometimes I'll go so far as to have specific logs for different sets of functionality within the same application, but it depends on the size & complexity of the app. I just use CFLOG and let CF manage the size limits and archiving. No sense reinventing the wheel.
If you get inspired about logging and exception handling, let me know. I've got some very useful logging abstractions in Tardis that you can use for doing error notification to a logging and notification *mothership*. The idea is to implement a system that support developers can subscribe to an application and get notifications when an application throws an error of a pre-defined severity. Then they would take ownership of the error and be responsible for remediation. The mothership idea is still in my head at this point, but the abstractions are already there in Tardis to use and go down that road. S ----- Original Message ---- From: Dean H. Saxe <[EMAIL PROTECTED]> To: discussion@acfug.org Sent: Thursday, May 29, 2008 6:36:06 AM Subject: Re: [ACFUG Discuss] error handling Shawn, Totally agreed, couldn't have said it better myself. Dusty, please don't present the exception in a HTML comment, anyone who is looking for it will find it and may use it against you. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] "To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Theodore Roosevelt On May 29, 2008, at 6:22 AM, shawn gorrell wrote: > Dusty, I have some code that I'll send you off-list of example > cferror and onError implementations with notification. You have to > be very careful with it, because you don't want it to become a > potential denial of service vector. My samples include notification > throttles that will shut off at a preset number of notifications and > can be reset by a command. > > Something to keep in mind though is that cferror and the sitewide > error template are NOT an exception handling strategy, they are just > last lines of defense. If you do your exception handling in a > correct and layered fashion, those last lines of defense will almost > never get used. If a sitewide error template or cferror routinely > get called, you have systemic problems in your application that > should be remediated. But that said, you should still implement > those and NEVER present an end user with a naked CF error. Not > because they are ugly, but because they can expose information that > is a security threat. > > ----- Original Message ---- > From: Dusty Hale <[EMAIL PROTECTED]> > To: discussion@acfug.org > Sent: Wednesday, May 28, 2008 9:18:00 PM > Subject: [ACFUG Discuss] error handling > > I was wondering if anyone wanted to discuss best approaches to error > handling for cf sites. I want to implement some very basic error > handling for one of my sites. Basically I just don't want the ugly > cf errors to display for users of the site. I would also like to be > notified via email when an error happens and better yet get the > error information. Is the best approach still the <cferror> tag? Is > there a newer or better approach or best practice? Anyone got some > code they could share? > > Dusty > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by FusionLink > ------------------------------------------------------------- > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by FusionLink > ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------