no error messages appear on the screen. You should always use one, but all
your actual error trapping should be done with CFTRY..CFCATCH if at all
possible.
If you're using something like Fusebox or Mach-ii, it's a snap, because
everything goes through a single template (index.cfm) before being delegated
to one of the various request handlers. Just put your CFTRY..CFCATCH in
there. If you've got a "normal" app, where each page is it's own template,
then you're kind of stuck, unfortunately, although you can come close to
duplicating by doing something like this in every template:
<cftry>
<!--- all template content goes here --->
<cfcatch type="any">
<cfinclude template="/error/errordispatcher.cfm" />
</cfcatch>
</cftry>
Then in "errordispatcher.cfm" you can use the CFCATCH variables to determine
what to do (different error types), and you still have full access to all
the CF tags you could ever want.
That won't handle 404s and such, so in your actual CFERROR template, I
usually use a client-side redirect to forward back to my application, to an
error page, so I can once again use all the CF tags. You need to be careful
with that page though, because you could end up in an infinite loop. It HAS
to be defined, and it should only use CF, no external resources at all (DB,
web services, network shares, etc), because that might be the base cause of
the error.
Bottom line, the CFERROR templates should be as dumb as possible, becase, as
you've seen, they are so devoid of function to be almost worthless.
Cheers,
barneyb
> -----Original Message-----
> From: Pete Ruckelshaus [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2003 11:11 AM
> To: CF-Talk
> Subject: cferror causing me pain
>
> CF MX 6.1/Windows XP
>
> I'm trying to implement some site-wide error handling using
> cferror, and
> it's really being a PITA.
>
> In my application.cfm file, at the very end, I have:
>
> <cferror type="EXCEPTION" template="/error/error.cfm" exception="ANY">
> <cferror type="REQUEST" template="/error/404.cfm">
>
> error.cfm and 404.cfm are both in /error/, I have verified
> this. After
> I made this change, I restarted services and then loaded a test page
> with an error in it. Instead, I got the standard exception error
> handling page (not my page). After about 30 minutes of
> screwing around,
> I went into CFAdmin and registered /error/error.cfm as the
> default error
> handler, and lo and behold, it worked. I then went in and
> removed that
> setting from CFAdmin and it still worked. Has anyone else seen this
> behavior?
>
> Second problem is the request error page, /error/404.cfm
> That page is
> being loaded as expected when I force a request error, but I
> cannot for
> the life of me get the error variables to display as they
> should. It is
> my understanding from
> http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/tags-p2
> 4.htm#wp2022557
> that I can display a number of variables, but cannot
> otherwise use any
> CF tags. Well, here is /error/404.cfm, and it doesn't
> display the value
> for error.browser (it displays #error.browser# like it's expecting a
> cfoutput tag):
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <title>Untitled</title>
> </head>
> <body>
> <h1>404</h1>
> #error.browser#
> </body>
> </html>
>
>
> When I do put #error.browser# inside cfoutput tags, it throws
> an error.
>
> What am I doing wrong? All I want to be able to do is display a form
> that will allow the end user to submit feedback, and part of
> that form
> will be these error variables in hidden form fields.
>
> Thanks,
>
> Pete
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
