> effort to make sure 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.
I would strongly disagree with this (not that my opinion is any better than
yours!)
I run into a lot of people using CFTRY/CFCATCH around their entire page, and
I think it's a waste. I'd strongly recommend reserving the use of CFTRY and
CFCATCH for situations where you have an expected problem with a specific
algorithm, and a specific solution for that problem.
> 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.
You have full access to all CF tags using CFERROR TYPE="EXCEPTION", CFERROR
TYPE="MONITOR", and the site-wide error handler. Given that, what's the
advantage to using CFTRY in this case?
> 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.
In general, I'd agree with this part - your CF error handlers have to be
careful not to trigger an error. However, if you use the site-wide error
handler, or CFERROR TYPE="EXCEPTION", and your error handling page has an
error, it won't trigger an infinite loop, but will instead throw to the
built-in CF error handler and you'll get the big white error page we all
know and love. However, if you do the redirect that you're talking about,
you may well get in an infinite loop.
> 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.
This used to be true, but I don't think it is true at all any more. I find
CFERROR and the site-wide error handler to be immensely useful.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
