One common things folks may do when using try/catch in CFML is to simply cfdump the CFCATCH object. I know that I, probably like most folks, assumed that the CFCATCH variable was a structure. It looks like a structure (with values like cfcatch.tagcontext) and most x.y things in CF are structures, so it was probably a safe assumption. However, there are times when dumping cfcatch will not result in a nice little struct. Instead you get something like this:
This was generated from the following code:
<cfset x = structNew()>
<cfoutput>#x.y#</cfoutput>
<cfcatch>
<cfdump var="#cfcatch#">
</cfcatch>
</cftry>
What is interesting is that it seems to be only a specific type of error: coldfusion.runtime.UndefinedElementException. If you change the code above, let's say to foo() (a udf that does not exist), the dump works correctly.
So what to do? You could switch to a more manual approach:
<table>
<tr>
<td>Type:</td>
<td>#cfcatch.type#</td>
</tr>
<tr>
<td>Message:</td>
<td>#cfcatch.message#</td>
</tr>
<tr>
<td>Detail:</td>
<td>#cfcatch.detail#</td>
</tr>
</table>
</cfoutput>
This works nicely, although for the original error, the detail row is blank. You could also add more detail, like the tag context, etc.
So, this was discussed on cf-guru quite a bit. Sean Corfield made the point that the documentation does not explicitly state that cfcatch is a structure. However, I think it's current behaviour would be considered a bug. I'd be willing to bet that this particular CF exception has a simple bug in it that makes it not work quite well with cfdump. Either way it is something to keep in mind.
Archived Comments
I ran into this a long time ago, and decided to write a custom tag that could deal with dumping the "non-struct" cfcatch value.
The thing is, though, that sometimes certain properties aren't available in the exception object--even though they should be--and another exception is thrown when trying to access them.
Note that accessing cfcatch.message, cfcatch.type etc implicitly call the getMessage(), getType() etc methods on the underlying object in this case.
You can also call cfcatch.toString() which will produce something readable I expect. You can also call cfcatch.getStackTrace() which gives you an array of (Java) stack trace elements.
cfdump can only "pretty print" object types it knows about (although it does seem a little strange that it doesn't recognition this particular CF exception) - it's worth remembering that while something is 'clearly' a CF type to you, underneath they are all Java types...
And, I think, Sean, that is why this is a "bug" -- if I have to know anything about what happens "under the sheets" to use a CFML construct, something is not right.
It's nice to be able to know something about what's going on under the sheets, but it surely shouldn't be necessary for me to understand it to use CFML (if for no other reason because of backwards compatibility -- the test case Raymond uses to make the java CFCATCH works just fine in CF5 as a struct).
As I said, accessing cfcatch.type, cfcatch.message works and that is what is documented. I don't think the behavior of cfdump var="#cfcatch#" is documented. Therefore it is not technically a bug.
And I do think that CFers need to be aware of what is under the sheets these days. Even if only to recognize that every CF object is really a Java object.
Maybe what is really needed is a more robust <cfdump> that is cabable of handling known java objects such as Exception.
I can certainly see benefit in extending cfdump so that if it finds any methods of the form (using reflection):
simpletype getXxx()
it calls them and displays the results as:
property xxx value
Of course, there is the danger that the getXxx() has a side effect (e.g., getNextSequenceID()) so you would probably need more fine-grained control over the behavior of the tag...
Sean, why would it need to call the methods? Why wouldn't the reflection simply get the method names.
FYI, as a personal aside, when I worked at Macromedia I did some of the work inside cfdump, including reflection. It _does_ have basic reflection support for Java objects, but I don't think it goes very deep.
Sure would be nice if the location of where the error occurred would be provided for these types of errors.
Ray, I was thinking about how it could show type / detail / message even for Java exceptions by calling getType() / getDetail() / getMessage().
Well, aside from the name of the method, you also can get its return type. I say that if the return type is a simple type (string, integer, float, boolean, etc.) or is a known complex type (array/vector, query/recordset, struct/HashMap/Collection) then it dump that value.
No, its not a simple order to fill but it would be very useful once done.
While we're at it, I also think that <cfdump> should be updated so that the CSS it uses works when you use XHTML by prefixing all hex color values with "#" and properly placing the generated CSS inside the <head></head> tags. Just for completeness...