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:
(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:
This is a really general to the blog section, but even in there, we can get more specific:
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:
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.
Want to use code from this post? Check out the license.
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.
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.
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.
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.
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?
On a somewhat related note, apparently using JavaLoader interferes with the ability to target specific exceptions with the TYPE attribute of CFCatch: