Thanks for the in-depth analysis, Mosh!
Concerning this comment:
"This is still valid with one caveat; you
must put CFOUTPUT tags around any variables used in the request
handler."
I found that out when I followed your suggestion to <CFINCLUDE>
the user display page from within the admin diagnostic page.
I ended up putting this on the application.cfm:
<CFERROR Type="Exception" Template="error_admin.cfm"
Exception="Any" mailto="[EMAIL PROTECTED]">
Then, from within the "error_admin.cfm" page, I put:
<CFINCLUDE Template="error_user.cfm">
I could send my mail using a <CF_Dump var=#Error#> custom tag to
send the error info to my email, and have the "CFIncluded" error_user.cfm
page display the error info to the user. (After putting the <CFOUTPUT>'s
around message for error variables.)
It's going to be great having these error messages show up in my email
when a user has a problem. Now, I'll be able to call them right away,
if needed, instead of waiting until they get frustrated and have to call me!
Thanks again!
Rick
-----Original Message-----
From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 19, 2002 12:55 AM
To: CF-Talk
Subject: RE: cferror
Mosh Teitelbaum wrote:
> ... there's no reason why you can't specify multiple CFERROR
> TYPE="Exception" tags as in:
>
> <CFERROR TYPE="Request" TEMPLATE="request_error.cfm">
> <CFERROR TYPE="Exception" EXCEPTION="Database"
TEMPLATE="db_exception.cfm">
> <CFERROR TYPE="Exception" EXCEPTION="Application"
TEMPLATE="app_exception.cfm">
>
> I don't know what would happen though if you did the above and
> also included an EXCEPTION="All". Would it catch everything,
> ignoring the other tags, or would it catch everything not
> specified in the other tags. Order might matter in this case (as
> it does when declaring CFCATCH blocks). Dunno... if I have some
> time tonight, I'll try to remember to test it out.
So I did some testing and, for those that are interested, what follows is a
summary of the findings and some items to note:
ColdFusion lets you define multiple instances of the CFERROR tag. The two
attributes we're concerned with here are TYPE and EXCEPTION. TYPE="Request"
is something of a catch all declaration that will catch all exceptions not
handled by other CFERROR instances and exceptions caused by other error
handlers. TYPE="Exception" allows you to define handlers on a per exception
basis using the EXCEPTION attribute which can specify the name of a single
exception type or the word "Any" which, like TYPE="Request", catches all
exceptions not handled by other instances of CFERROR.
If you specify EXCEPTION="Any", than a TYPE="Request" is used only when an
exception is generated in an error handler. That is, the EXCEPTION="Any"
essentially relieves TYPE="Request" of it's role as a catch-all.
EXCEPTION="Any" will only catch those exceptions not otherwise handled by
other EXCEPTION="" definitions. So, with the following code:
<CFERROR TYPE="EXCEPTION" EXCEPTION="Any" TEMPLATE="any.cfm">
<CFERROR TYPE="EXCEPTION" EXCEPTION="Expression"
TEMPLATE="expression.cfm">
<CFERROR TYPE="EXCEPTION" EXCEPTION="MissingInclude"
TEMPLATE="missingInclude.cfm">
An Expression exception will be handled by expression.cfm but any OTHER type
of exception will be handled by any.cfm. Order of declaration does not
matter.
As I mentioned above, when you declare EXCEPTION="Any", TYPE="Request" is
only used to catch exceptions caused by an exception handler. Even if the
type of exception thrown by the handler has a defined handler (for example,
if the Expression handler in the above code causes a MissingInclude
exception to be thrown) it will be handled by the Request handler, not the
Exception handler.
Finally, I had suggested earlier in the thread that, instead of maintaining
multiple displays to inform the user that an error occurred, you can simply
define it once -- in the Request handler -- and just include the request
handler from your other handlers. This is still valid with one caveat; you
must put CFOUTPUT tags around any variables used in the request handler.
All exception handlers (including Request) can access several variables from
the ERROR scope. However, the request handler is limited in that it cannot
make use of CFML so, to output the variables from the ERROR scope, you
simply escape them with pound signs, no CFOUTPUT needed. But, if the
request handler is executed by way of inclusion from another exception
handler, it will be executing in the "role" of a non-request handler, i.e.,
it needs CFOUTPUT. Because the request handler simply ignores CFML syntax,
you can wrap the variables with CFOUTPUT tags and everyone is happy.
So that's it. I hope this is helpful.
--
Mosh Teitelbaum
evoch, LLC
Tel: (301) 625-9191
Fax: (301) 933-3651
Email: [EMAIL PROTECTED]
WWW: http://www.evoch.com/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
