The service fell over during testing and the log has a wall of text in it. Two hundred lines of class names, file names and line numbers. You scroll up and down, recognise none of it, copy the first line into a search engine, and hope.
This is one of the most useful things you can learn to read properly, and it takes less time than you would think. That wall of text is a stack trace. It is the program telling you exactly which chain of calls it was in when it failed.
Start by finding two things. The type of error and its message. Then the first line that mentions your own code. Everything else is context.
Where those live depends on the language. In Java, the exception and its message come first, followed by lines starting with at, each one a method call. The top one is where the error was thrown. Much of what follows may be framework code you can skip until you find a package name you recognise. In Python it is the other way round. The heading says most recent call last, so the error type and message are on the final line, and the call nearest to it is just above.
Then look for chained causes. In Java a trace often contains one or more sections beginning Caused by. Each one is an earlier error that was wrapped in a new one, and the last Caused by is usually the original failure. A message like failed to start the application at the top can hide a message like connection refused at the bottom, and that is the one you need. The lines ending in a number of more are not missing information, by the way. They are repeats of frames already printed above.
Now read your own line of code with the message in mind. A null pointer on that line means something there was null. Which thing, and where did it come from? That question will take you further than any search.
Practise on purpose. Next time someone on your team shares a trace, read it before you read their explanation, and see if you reach the same line. After a few weeks, the wall of text will become a map.
– Asael Shinder
Top comments (0)