Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at CFUNITED 2009 (Lansdowne, VA) with:

ColdFusion CFCatch Tags Catch Exceptions Based On Type Hierarchy

By Ben Nadel on
Tags: ColdFusion

I learned an interesting fact from Brett last night at the New York ColdFusion User Group - ColdFusion's CFThrow / CFCatch combination works in a hierarchical fashion based on the dot-notation of the exception type being thrown. What this means is that as you add "dot-something" to an exception type, it becomes more specific. For example, my blog might throw a bunch of "kinky" exceptions:

Kinky

(This is all theoretical - my blog doesn't throw custom exceptions) However, if an error happens in the blog, it might throw a blog exception:

Kinky.BlogException

This is a really general to the blog section, but even in there, we can get more specific:

Kinky.BlogException.EntryNotFound

EntryNotFound is a type of BlogException which is a type of Kinky exception. That's what I mean when I say hierarchical.

Now, when it comes to catching errors that bubble up through the pipeline, most people just use a single CFCatch tag to catch all errors. You can, however, specify the type of error that gets caught by a specific CFCatch tag. This allows you have multitple CFCatch tags in a single CFTry / CFCatch statement, each of which is listening for a different type.

All that stuff, I already knew; what was new to me was that the CFCatch tag will catch errors based on the exception hierarchy. What I mean by this is that if you have a CFCatch tag that is listening for exceptions of type "Kinky", it will catch exceptions of type "Kinky" as well as type "Kinky.BlogException" because "Kinky.BlogException" is a sub-class (if you will) of the "Kinky" exception type.

Let's run a quick demo to see CFCatch in action:

  • <cftry>
  •  
  • <cfswitch expression="#RandRange( 1, 4 )#">
  • <cfcase value="1">
  •  
  • <!--- Throw exception. --->
  • <cfthrow type="Kinky" />
  •  
  • </cfcase>
  • <cfcase value="2">
  •  
  • <!--- Throw exception. --->
  • <cfthrow type="Kinky.BlogException" />
  •  
  • </cfcase>
  • <cfcase value="3">
  •  
  • <!--- Throw exception. --->
  • <cfthrow type="Kinky.BlogException.EntryNotFound" />
  •  
  • </cfcase>
  • <cfcase value="4">
  •  
  • <!--- Throw exception. --->
  • <cfthrow type="Kinky.InvalidUserAgent" />
  •  
  • </cfcase>
  • </cfswitch>
  •  
  •  
  • <!--- Catch all blog exceptions. --->
  • <cfcatch type="Kinky.BlogException">
  • <cfoutput>
  •  
  • <p>
  • #CFCATCH.Type#<br />
  • Kinky.BlogException
  • </p>
  •  
  • </cfoutput>
  • </cfcatch>
  •  
  • <!--- Catch all kinky unhandled kinky errors. --->
  • <cfcatch type="Kinky">
  • <cfoutput>
  •  
  • <p>
  • #CFCATCH.Type#<br />
  • Kinky
  • </p>
  •  
  • </cfoutput>
  • </cfcatch>
  •  
  • </cftry>

Notice that in this demo, we are throwing four possible exceptions, but only catching two types of exceptions. Running this code a few times, we get the following output:

Kinky.BlogException
Kinky.BlogException

Kinky.InvalidUserAgent
Kinky

Kinky
Kinky

Kinky.BlogException.EntryNotFound
Kinky.BlogException

Kinky.InvalidUserAgent
Kinky

Kinky.BlogException
Kinky.BlogException

Kinky.BlogException.EntryNotFound
Kinky.BlogException

Notice that the even though we had only two CFCatch tags, we were able to catch all four thrown exception types. This is because our CFCatch tags were catching general exception types which covered both the general and the more specific.

This seemed pretty cool to me. Overall, I have not really made much use of custom exceptions and exception handling, but the more I see it, the more it is something that I want to get into.




Reader Comments

After all the tidbits I've learned from this blog over they years I'm glad I was able to give back. I've always enjoyed the way you get under the hood on your posts.

I use cfthrow *a_lot* and I've learned some other tricks and techniques that really come in handy. Perhaps I can follow on at another NYCFUG in the future.

cheers,

.brett

Reply to this Comment

@Brett,

I am slowly getting more and more into exception usage. For the longest time, I had this weird feeling like I had to protect my users; I was always drying to recover from invalid data formats that would *only* occur if someone changed the HTML (ex. Altering a SELECT menu to return non-numeric values). For some reason, I felt the need to NOT give errors to people who were malicious.

But, that is changing. I no longer feel like I need to protect people from themselves. I am getting more comfortable with presenting error pages when people forcibly cause errors.

But, more than that, I am finding exceptions very useful for lots of other things. Right now, I am using them heavily within a web service API that I have for an AJAX application - the entire API is wrapped in CFTry / CFCatch and the different sub-parts can throw exceptions that the API will catch and return a more meaningful API response.

Anyway, cool stuff.

Reply to this Comment

I'm nibbling around the edges on this. It seems that exceptions could be a great tool, but I'm not quite seeing how I can integrate them. Do you have any other posts regarding their use? Especially custom exceptions.

Reply to this Comment

@Don,

I have started to use exceptions more in validation; but, I am nowhere near having anything that I'm happy with. Still working on it.

Reply to this Comment

cfCatch uses different struct keys (not really struct keys but they look like struct keys) based on what the cfCatch.type attribute is.

I like to build nice, well layed out error emails to parties involved. How do I know what keys are passed given any particular cfCatch.type key?

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.