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
-------------------------------------------------------------
