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.
This goes against the whole idea of how exception handling should be
structured in an application. For a diagrammed explanation of the three
"tiers" of structured exception handling, see page 430 of The ColdFusion MX
Bible. If you don't have a copy, here's an explanation that might help.
Envision a framework that has three layers...
The top layer contains one or more sieves that CFCATCH exceptions thrown by
your application. Each sieve catches a specific type of exception
(type="Database", type="_expression_", etc) that you expect might reasonably
occur in your application, such as a unique index violation on an alternate
key column that would be thrown by the database if someone tried to register
twice using the same email address.
This is a fairly coarse test, so you would further test inside the CFCATCH
construct for the NativeErrorCode that applies to the specific
type="Database" exception you want to handle. If the exception is the one
you want to handle in an "exceptional" manner, the code inside your CFCATCH
type="Database" construct would take over and handle it. If it was some
other type="Database" exception, you would CFRETHROW the exception you
"caught" back out of the top layer, down to the second layer in the
exception handling framework.
If an exception isn't handled by the top layer of CFCATCH constructs --
either by not having a CFCATCH of the type that was thrown, or by catching
and then RETHROWing the exception -- then it becomes a bona fide "error." I
know that exceptions and errors are thought of as the same thing, but it
sometimes helps to conceptually separate them in your mind this way, where
exceptions result in handling the flow of work in some "exceptional" manner
(not just displaying a more friendly error message), and errors are
exceptions that stop the flow of work because there is no exceptional
process to follow when them occur.
One indication that your exception handling "top layer" might be doing the
wrong job is if more often than not you specify type="Any" or altogether
omit the type attribute from CFCATCH. If you are doing this most of the
time then you're probably using CFTRY to improperly perform CFERROR's job,
which is the second layer in the exception handling framework.
The second layer contains one or more sieves that handle errors. Each sieve
corresponds to a specific error handler -- either an error handling template
installed via CFERROR or a CFCASE construct that tests for exception type
inside a multi-use error handling template -- and typically logs the error,
displays a friendly error message, and possibly emails the developer.
If an error handler for the specific type of error thrown wasn't installed
via CFERROR, then that error falls through to the site-wide error handler,
which is the third layer of the exception handling framework, and is more
like a solid-bottomed catch basin in this metaphor. I refer to these as
"crashes" because they should typically have been handled by an error
handler, and often suggests a more serious problem.
Setting up a structured exception handling framework like this enables you
to really leverage ColdFusion's exception handling capabilities. Take for
example the guy who tries to register twice on your website. Are you first
SELECTing from the user table based on his email address, checking the
RecordCount, and then conditionally INSERTing only if RecordCount EQ 0?
With properly structured exception handling, you simply attempt the INSERT
inside a CFTRY with a CFCATCH type="Database" that further tests
CFCATCH.NativeErrorCode for a value of 2601 (unique index violation on SQL
Server), then re-route the user to a page that not only describes exactly
what's going on, but also gives him an interface for emailing his password
to himself. An "exceptional" process flow for a specifically-handled
exception.
Another benefit is that you can use CFTHROW to nicely integrate your own
business logic into the same exception handling mechanism used by
ColdFusion's own exceptions. If your business rules define certain
anomalies as exceptions, even if those anomalies don't throw exceptions in
ColdFusion, you can throw a custom exception via CFTHROW and let your
structured exception handling framework kick in and do whatever is
necessary. Using dot notation in the values of your type attributes
(type="BusinessRules.Inventory.UnderLimit") enables you to do some pretty
fancy things, but that's another discussion altogether.
We spend a good bit of time teaching proper structured exception handling in
our ColdFusion MX Master Class because it really does make applications
easier to design, build, and maintain, and you don't end up writing
unnecessary and burdensome database queries and kludgey ColdFusion routines
to do something that's already built-in.
I hope this helps. If you would like to talk about exception handling in
person then please feel free to call me at 770-446-8866. I'm on Atlanta
time (EST), but I'm often in late (like now) so if you call after hours I
might be in.
Have a good one! :)
Respectfully,
Adam Phillip Churvis
Member of Team Macromedia
Advanced Intensive ColdFusion MX Training
ColdFusion MX Master Class:
January 12 - 16, 2004
http://www.ColdFusionTraining.com
Download CommerceBlocks V2.1 and LoRCAT from
http://www.ProductivityEnhancement.com
The ColdFusion MX Bible is in bookstores now!
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
