Read the error message

A Windows error message

This post is brought to you — indirectly — from a boss I loved working for, on a project which almost killed me, at a company which I had to walk away from to restore my mental health.

I learned a great many things from my boss (and yes, we are still friends). I learned about level 80 in World of Warcraft. I learned how using the static keyword in just the wrong place in your C# code can render even the best-designed security useless. I learned that working 16 hours a day for six days a week is a recipe for burnout.

And I learned how to read an error message.

My boss got upset with us one day on The Project From Hell. Tempers were frayed, tensions ran high, and other euphemisms were euphemisming. In short, we were all grumpy, and as expected on a project of this nature we kept making obvious mistakes and wasting our energy chasing our tails.

Obvious? Well, yes. It turns out that the answer to a particularly common issue we were running into was explained in the first line of the stack trace of the code that kept crashing. I’m not exaggerating for the sake of this story. The actual problem was explained in the first sentence of the error, in the very first line.

The thing about errors is that our eyes gloss over and we try and close the message as quickly as possible to make it go away. Exceptions make us feel bad, like we did something wrong. What we tend to forget though is that computers don’t know what we’re thinking. They do what we tell them to, and not what we want them to do. If programming were wishful thinking, I wouldn’t have needed to spend 16 hours a day doing it.

With a few exceptions (pun intended), error messages in Microsoft products are surprisingly well-written. Not only do they tell you what went wrong; in some products they will tell you where it went wrong, even down to the line and character in your code. Considering how complicated a code compiler is, this is very impressive.

Aside: the Rust language compiler is incredibly good at telling you what you’re doing wrong, how you’re doing it wrong, and how to make it right. Check it out if you want to see a modern approach to writing cross-platform code.

It’s very easy to shut down your brain when you see an error on the screen and ask someone else. It’s easy to close the message, click on the X, close the window. But here’s a funny thing I worked out after my boss got upset with us on that day in early 2008. He was right. The error message told us what we were doing wrong, and after a short chat with my boss, also how to fix it.

When my father was still alive he would make me look up a word in a dictionary if I didn’t know it, and then I would have to write it down in a notebook. It seemed mean at the time that he just didn’t tell me, but I learned how to use a dictionary very quickly as a result.

If you’re reading this, chances are you have spent several years using a computer. In that time, you may have seen hundreds, if not thousands or even millions of error messages. The next time you see one — and your first instinct is to ask someone else — I would like to challenge you to figure it out yourself. Chances are you’ll learn from it a lot better than relying on someone else.

Please: read the error message. Parse it in your mind. Break the sentence into components and understand each one. Even simple things will make a big difference in your work as a developer or database administrator, if you can tell the difference between an invalid operation exception and a null reference exception.

Of course, I don’t have an issue with you asking for help if you’re stuck. That isn’t the same thing. But at least give it a minute or two and think it through. You’ll thank me, like I thank my ex-boss.

(Image source)

2 thoughts on “Read the error message

  • Another good programming trick that I like to do is if I KNOW that a certain piece of code can produce an ugly error with a stack trace, try to catch it and present the end user with a more friendly message. Something like “oh no. Something went wrong. Please validate your input and if you are certain it is correct, submit a support request and include the file .” Or even better, have the application have a one-click button to submit the error and all of the logs and user input that are needed when you catch the error. I know end users who see the stack trace dumps and immediately think they did something bad so they better not tell anybody.
    Now catching ALL of those is nearly impossible, but when an end user sees one and brings it up with you or your team, you now have a chunk of code (or a line) that can benefit from a TRY CATCH or a logic change so it never throws an error.

    Now, I’m not saying put your TRY CATCH blocks everywhere as that is excessive and unneeded. i also HIGHLY recommend not having empty catch blocks. There are cases where it MAY seem to make sense to have empty catch blocks, but in those cases, it probably makes even more sense to handle the logic better so you don’t even need the TRY CATCH blocks.

    But I 100% agree with you here – read the error message and try to solve the problem yourself. Your image at the top as an example, I feel should have an IF statement on it rather than a stack trace.to the end user. IF dueTm > 2^32-2 THEN ELSE . BUT if an end user saw that stack trace, they should (hopefully) be able to read it and figure out the problem rather than putting in a support ticket for it.

    • Presenting an understandable error message to the end user is a good development practice. In .NET for example, you can intercept the exception type and handle it in a more elegant way, certainly. Of course that doesn’t mean “something went wrong”. Make it actionable. That said, this post is geared more towards the tech folks who run to StackOverflow or a mailing list without putting in any effort.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: