Rick... sorry I didn't respond sooner about your initial "blank screen
.. I think that was the same problemquestion"

-----Original Message-----
From: Rick Faircloth [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, December 19, 2002 2:04 AM
To: CF-Talk
Subject: RE: cferror

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
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm

Reply via email to