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:

   view plainprintabout
1  <cffunction name="onError" returnType="void" output="false">
2      <cfargument name="exception" required="true">
3      <cfargument name="eventname" type="string" required="true">
4      <cfset structDelete(arguments.exception, "stacktrace")>
5      <cfdump var="#exception#">
6      <cfabort>
7  </cffunction>

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:

   view plainprintabout
1  <cfdump var="#exception.getClass().getName()#">

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?

   view plainprintabout
1  <cfset var ex = duplicate(arguments.exception)>
2  <cfset structDelete(ex, "stacktrace")>
3  <cfdump var="#ex#">

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:

   view plainprintabout
1  <cfset var newEx = structNew()>
2  <cfloop item="key" collection="#arguments.exception#">
3      <cfset newEx[key] = duplicate(arguments.exception[key])>
4  </cfloop>
5  
6  <cfdump var="#newEx#">
7  <cfdump var="#newex.getClass().getName()#">

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

   view plainprintabout
1  <cfset newEx.stackTrace = left(newEx.stackTrace, 100)>

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:

   view plainprintabout
1  <cfoutput>#left(arguments.exception.stacktrace,10)#</cfoutput>

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