Rys Sommefeldt

Learning to read error messages

One of the biggest benefits to my productivity as a programmer over the years, and as a computer user in general, has been learning to read error messages properly when they occur. As a wet-behind-the-ears hacker, self taught and without any to-hand literature or manuals or the benefit of Google to help, I quickly learned to closely read what the tools of my craft were telling me when I was building and using software on the computer systems I was interested in.

These days it’s all too easy to get a build- or run-time error and just feed the last bit into Google. I know because I do it myself, but I’ve taught myself to only do so as a last resort.

In my experience, the vast majority of the time software fails to build or run you get a descriptive error message and usually a line number in a source file to go and investigate. I’ve only really come unstuck when using older C++ compilers and a codebase that makes liberal use of templates, where the compiler’s error is masked by something else going wrong elsewhere in the source as it’s being parsed. At Plusnet, there was an awful web framework that spat out stack traces thousands of lines long after an exception, as the exception bubbled up, leaving the top of the trace talking about something miles away from the actual call site that triggered the failure.

I recommend just reading first before searching where at all possible. You might get to the solution slower, but you’ll learn more and go faster next time, and the advice applies to working with software of any kind and regardless of whether you’re programming it.

If the error message truly is terrible, make an effort to ask the developer to improve it for next time, even if you think someone else will so you don’t have to bother. The web is littered with millions of pointless pages, blogs and forum posts asking about things you could solve yourself if you just took the time to read.