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 Force.com 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||System.NullPointerException: Attempt to de-reference a null object 13:30:17.139|METHOD_EXIT||IntakeBusinessLogic.benefitIndependent() 13:30:17.139|METHOD_EXIT||IntakeBusinessLogic.execute() 13:30:17.139|METHOD_EXIT||CmsCalloutController.doSave() 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 Class.CmsCalloutController.save: 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.