How to read a stack trace and fix problems
To be honest, I could probably write a book about this subject. I would include all sorts of stack traces — lots of mini-chapters, so to speak — and then describe how I figured out what the problem was, and fixed it.
Unfortunately, this would be a very boring book, because every time, I do exactly the same thing.
Kids, developers, random internet denizens, listen up and listen good — and use a hammer to get this into your head, if need be:
How to fix a Java problem when you have a stack trace
- Find the stack trace.
- Follow the
Caused by:‘s until you’ve found the root stack trace.
- Search the web for the exception (or code line).
- If the web gives you an answer back, go apply the answer!
- If the web doesn’t give you an answer back, go debug the problem and find out what’s happening at the line of code!
- If you run into a new problem, start over!
Sometimes, you don’t want the root cause — but very rarely. Lastly, and I really shouldn’t have to say this, please think about why exactly the stack trace happened. What is the stack trace actually saying?
Obviously, sometimes, you will have no clue what the heck the stack trace is saying. In this case, you are faced with a golden opportunity to learn something! Learning what a stack trace is actually saying will only expand your knowledge and make you a better programmer. It will make you a better programmer because you will become aware of how programs actually work in the real world, and what types of problems are common.
To tell the truth, we’ve touched on 3 intrinsic skills you better have or learn if you want to fix code problems:
- a. Learning how Java works (stack-based architecture of the JVM) — and thus, which parts of a stack trace are important.
- b. Understanding what other people say or type and being able to apply that knowledge to your own (technical) situation.
- c. Knowing how to debug.
I’m actually not sure which of these 3 is the most important or hardest. I’m tempted to say that c is probably the easiest, although many people (can you say Dunning–Kruger?) probably think c is the hardest. I know that I’m still figuring out how the JVM and Java work and that understanding what other people say or write is something that will keep challenging me for the rest of my life.