If you have a question about an error which you observed on a system, you will often be asked for a Stack Trace of the exception.

If you’re not used to analyzing those Stack Traces, they may look quite intimidating and you may wonder what other people are going to do with such intimidating long lists of information.

You may be surprised how useful a Stack Trace can be in “post-mortem analysis”. That is: in analyzing what went wrong after the misery happened (if you don’t have access to a system with debugger where you can easily reproduce the situation).

To illustrate how much information you can get from a Stack Trace, in combination with having access to the source code, see this Q&A on Tridion Stack Exchange: https://tridion.stackexchange.com/questions/18997/dxa-1-8-java-application-error

In this case, it is about an exception happening within the DXA Framework and the DXA source code is publicly available on GitHub.  I wanted to point out how to navigate to the right version of the source code, based on the information available in the Stack Trace and how much you can conclude by only carefully inspecting the Stack Trace.

OK, maybe the analysis is a bit intimidating in itself. [:)] But I hope you catch my drift and it inspires you to develop your post-mortem analysis skills, so maybe you don’t even have to post a Question on Stack Exchange anymore next time you encounter an exception.  Or at least you will be aware of the value of a Stack Trace and immediately provide one if you can’t figure it out yourself.