By Masha K.
Aug 14, 2019
Are you familiar with that red wall of text in your log? The kind that never seems to disappear; it just alters and jumps from place to place? Errors seem to be one of the most common causes of frustration for developers. We expect something to work, and it doesn’t. And then it laughs at us with that stack trace.
With time, every developer learns to love error messages. Believe it or not, an error message can be your friend, not an enemy. And if you don’t love it yet, you should try and embrace the frustration that it causes.
Why? For a minute, imagine a world without error messages. Something doesn’t work as expected, and you have no idea which cog is broken. Your build log is in black and white, your tests are of that pretty shade of green, and yet your QA throws at you one bug ticket after another.
That would be pure hell, wouldn’t it? That’s why, when I see red, I feel safe. I feel like all is gonna be alright, because this red wall of text is gonna tell me exactly what’s wrong with my code.
Yes, eventually. When you learn to read it.
You have no idea how many times people asked for my help with understanding the errors thrown at them by their code.
“It doesn’t work” or “There’s an error,” they blurt out, hoping for a savior.
“What error?” I respond. “What exactly does the message say? Do you know what it means? No? Let’s google it.”
First, a Stack Overflow post usually solves the problem. Then, people feel grateful to me for some reason, even though all I did was (miraculously) copy and paste the error into Google and click on the first result.
Googling helps at first, especially with unfamiliar frameworks and libraries. But at some point you should learn to read the stack tracebecause the most valuable information is there – file name and line number.
That’s where the error happened, the place from where the torpedo was launched, crippling your program. Even if the error wasn’t generated by your code, you should be able to follow the stack trace to the familiar ground, which is a file in your repository. Once you’re there, look at the line and try to understand what went wrong. It’s your duty to unwind the mystery. Don’t feel overwhelmed, but pull the red thread and, step by step, it will lead you out of this mess.
It does sound easy, and it is – it’s our fear of the unexpected that clouds our reasoning. Stop being afraid (unless you’re debugging the software of a nuclear plant. In that case, why are you even reading this?). Take a deep breath and dig into the details. The more you do it, the more you will like it.
Now, what I’ve sketched out thus far is a basic approach that works with most setups and dev stacks. Sometimes there’s the added complication of not having an error log on hand, i.e. when the error happened in a remote environment to which you don’t have access. In that case, try and reproduce the error locally. When you do that, you can add more detailed logs or even shove a debugger into the code. That’s pretty much it.
But then there is the case of unreadable error messages.
The latter is illustrated beautifully by the “paamayim nekudotayim” case. This happened when a team of Israeli developers working on a PHP interpreter decided to name one of the operators in Hebrew. It was 1999, and everyone did what they wanted. Well, guess what: four major PHP versions and twenty years later, the message “Unexpected T_PAAMAYIM_NEKUDOTAYIM” still confuses juniors around the world.
This is art, guys and gals.
Don’t blame yourself if you stumble upon one of these. Follow the stack trace. Add logs. Read documentation. Call for help when totally desperate! And then *phewww, phewww, phewww*… yoga breaths. It’s gonna be fine 🙂