A reader posted an interesting comment to my ColdFusion Exception Handling Guide. He had modified his error handling to store the errors in a database. This allowed him to look at history exception information, do trending, etc. But he ran into trouble trying to remove the stack trace from the exception object. Here is an example of that.

Imagine a simple onError like so:

Doing this causes the error handler itself to barf out: cannot remove properties from a java object. While I knew that Exceptions were Java objects, I had always assumed that when ColdFusion got to it, it was a normal struct. When you cfdump it, you see a struct, which is very different from the normal Java object dump. However, you can see that it is not if you check the class name:

This returns coldfusion.runtime.UndefinedVariableException whereas a "real" structure would return coldfusion.runtime.Struct. Ok, so this implies that cfdump recognizes the ColdFusion exception and massages the output a bit. What happens if we try to duplicate the structure?

Unfortunately this returns the exact same error: cannot remove properties from a java object. So we still have a Java object after the duplicate. No surprise there I guess, but if cfdump had a 'hack' for ColdFusion exceptions I thought perhaps duplicate might.

I then tried this variation:

And bam - that did it. So at the key level the values came over correctly. And just to be sure, I then did this:

And bam - that worked perfectly.

Of course, this may be overkill. If you are inserting the values from the exception object into the database, you can simply do the left in your cfquery. So for example, this is fine:

I'm not modifying the actual Exception object, just the result of getting the string value.