I like to use a 2-pronged effort when it comes to error handling.
First of all, I establish a site-wide error handler in the CF
Administrator.  This is different than a 404 handler.  If it comes
down to it, this one tool can handle all CF errors on a particular
server for you.  That site-wide error handler can then use anything in
CF you like.  Including branching depending on what domain threw the
error, and doing different things per domain.  However, the simplest
form would be the code sample shown below.

This is basically a complete dump of everything, so you can wade thru
the mess and figure out just what happened.

However, thats painting with a pretty broad brush.  What if you pulled
a 500k query on the page that fried?  Then those query results would
be in your email, in the variables scope.  On top of that, what if
this was a secure form post and sensitive info is in the form scope?
So much for confidentiality.

You get around this by either dumping the data to disk if you have
confidential info.  Then you pull the data via some other secure
means.  Another really helpful thing is to design your apps so they
facilitate dumping data out if the necessity arises.  Don't just use
the 'variables' scope, for example, use a struct instead and then you
can dump just the struct rather than all the queries that go with it.

The latter approach works far better when you do it inside of an
individual application, and thats my second prong to this:  You
mentioned putting CFTRY into Application.cfm and terminating it in
OnReQuestEnd.cfm.  Sorry but it doesn't work that way, although I wish
it did.  You have to wrap *each* individual template in a try/catch
block, like this:

<cftry>

...your entire template goes here  ...

<cfcatch type="Any">
<cfinclude template="includes/errcatcher.cfm">
</cfcatch>
</cftry>

Since you are 'nesting' this catch block inside of your site-wide
error handler, it will take precedence and then you can have
application-specific error handling.  If you forget to do that, the
site-wide handler takes over.

Or you can have operation-specific error handling.  Wrap a block of
code in a try/catch block and it will take precedence over the block
that wraps the current template.

--
--Matt Robertson--
MSB Designs, Inc.
mysecretbase.com

<cfmail
to="[EMAIL PROTECTED]"
from="[EMAIL PROTECTED]"
subject="Error Report"
type="HTML">
<h3>Data Dump</h3>
<cfif isdefined("CFCATCH")>
<cfdump var="#cfcatch#" label="Error variables">
</cfif>
<cfif isdefined("FORM")>
<cfdump var="#form#" label="Form variables">
</cfif>
<cfif isdefined("CLIENT")>
<cfdump var="#client#" label="Client variables">
</cfif>
<cfif isdefined("SESSION")>
<cfdump var="#session#" label="Session variables">
</cfif>
<cfif isdefined("REQUEST")>
<cfdump var="#request#" label="Request variables">
</cfif>
<cfif isdefined("VARIABLES")>
<cfdump var="#variables#" label="Local variables">
</cfif>
<cfif isdefined("APPLICATION")>
<cfdump var="#application#" label="application variables">
</cfif>
<cfif isdefined("SERVER")>
<cfdump var="#server#" label="Server variables">
</cfif>
<cfif isdefined("CGI")>
<cfdump var="#cgi#" label="CGI variables">
</cfif>
</cfmail>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to