How to read a ColdFusion Stacktrace

This question came up recently:

How do you read a stack trace? Are there any resources that will educate me?

While there are many resources specific to Java on reading a stacktrace, I don't think there are many related to ColdFusion or CFML. So let's make one here.

Here's a part of a stacktrace that this particular user was wanting to understand better:

lucee.runtime.exp.NativeException: invalid hexadecimal String
 	at lucee.runtime.coder.HexCoder.decode(HexCoder.java:62)
 	at lucee.runtime.coder.Coder.decode(Coder.java:61)
 	at lucee.runtime.coder.Coder.decode(Coder.java:47)
 	at lucee.runtime.crypt.Cryptor.decrypt(Cryptor.java:194)
 	at lucee.runtime.functions.other.Decrypt.invoke(Decrypt.java:66)
 	at lucee.runtime.functions.other.Decrypt.call(Decrypt.java:45)
 	at cfc.utils.security_cfc$cf$w.udfCall(/cfc/utils/security.cfc:25)
 	at lucee.runtime.type.UDFImpl.implementation(UDFImpl.java:106)
 	at lucee.runtime.type.UDFImpl._call(UDFImpl.java:344)
 	at lucee.runtime.type.UDFImpl.call(UDFImpl.java:217)

Step 1: Start at the Top

The first line of the stacktrace will usually be formatted as type: message, the type is going to be the name of a java class that holds information about the exception, in this case it is lucee.runtime.exp.NativeException. In this case it is a Lucee server, but all the same ideas apply on a ColdFusion server. The message will hopefully give you a summary of what the actual problem is. Now I say hopefully, because this depends on how good the exception handling code is, we've all written a vague error message.

Step 2: Look for a cfm or cfc file

Next I work my way down the stacktrace starting at the top, looking for a cfm or cfc file. This tells me where in my code the exception originated from. If you can't find a cfm or cfc file, then it could be that the exception happened outside the context of your code (for example it could be thrown from Tomcat or ColdFusion or Lucee, etc before or after your code runs). In this example stacktrace we see a line:

at cfc.utils.security_cfc$cf$w.udfCall(/cfc/utils/security.cfc:25)

So now we can take a look at our code security.cfc and go to line 25, in this case it was:

decrypt(trim(ucase(arguments.inputString)), eKey, "AES","hex")

That tells us it was the decrypt function call, but we can see that by looking at the line above this line in the stacktrace. That is useful because there are a few CFML functions being called on that line of code, trim, ucase and decrypt, but we know from the stracktrace that the exception happened in the decrypt call.

In some cases you might want to keep going down the stacktrace and look for another CFML line, but you don't always need to look at the bottom of the stacktrace, usually the most important parts are at the top.

Step 3: Work back up the stacktrace

We can see how execution is traveling between several java functions calls once we call the decrypt function, all the way up to the second line of the stracktrace. The line:

at lucee.runtime.coder.HexCoder.decode(HexCoder.java:62)

This tells us that the class lucee.runtime.coder.HexCoder in the method call decode() on line 62 is where the exception was thrown from. Because lucee is open source, we can actually take a look at the actual code that threw the exception:

if ((hexa.length() % 2) != 0) {
    throw new CoderException("invalid hexadecimal String");
}

From that code we can tell that the length of the hex string passed in was an odd number!

If you want to play around with reading a stacktrace, here's an example on TryCF that you can play around with. In that example there are multiple function calls that you can follow the execution through.