Stack traces in the debug log

About the only time that you get a stack trace – the key line number information to find where an unexpected exception is coming from – in is for errors that are not handled and get emailed to the developer. If you handle an exception there is no way to extract the stack trace and it is lost. (Stack Trace with Exceptions is over 2 years old and unlikely to ever get implemented.) This is bad news during development and much worse news when you are in production.

While trying to track down a NullPointerException I resorted to turning on the (usually overly verbose) logging and at first glance didn’t think it was going to be much help. But then I noticed that in fact the line numbers are there in square brackets meaning that this debug log entry:

13:30:17.139|EXCEPTION_THROWN|[157]|System.NullPointerException: Attempt to de-reference a null object
13:30:17.139|CODE_UNIT_FINISHED|CmsCalloutController invoke(save)

contains the same line number information that this stack trace does just organized a little differently:

caused by: System.NullPointerException: Attempt to de-reference a null object

Class.IntakeBusinessLogic.benefitIndependent: line 157, column 13
Class.IntakeBusinessLogic.execute: line 132, column 9
Class.CmsCalloutController.doSave: line 176, column 74 line 143, column 32
External entry point

So at least in development you can (eventually) get hold of the line number information you need to fix the problem.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s