Do you track errors? You should, and here’s why
How the hell is this not working? I’ve done it 100 times before and my code is right, what is going on?
If you’ve never thought this, you’ve probably never coded.
It’s unavoidable. You will cause errors. Sometimes with relatively easy features, and other times with more complicated ones. If you combine all the time you’ve spent debugging, it will amount to a terrifying number. That’s time you’ll never get back.
So the goal should be to limit the amount of bugs you create in the first place, right?
That is a good goal but you’ll eventually hit a limit, especially if you’re stretching your capabilities with new things you’ve never done before (which you should be doing!).
Creating bugs is just a side effect of coding, period. So the next best goal should be to reduce the time it takes to identify and solve these bugs.
How do you do it?
- I’ve wrapped my code in print() and console.log() to spit out arrays and look at variables.
- I’ve written tests
- I’ve cried
- I’ve thrown things
And then I found a better way.
A better way to track errors
Are you aware that error tracking software exists? Have you used any of the solutions?
I figured something existed out there that could help, but I also thought it would be a pain to setup while providing very little help. I was so wrong. There are great solutions and they take a few minutes to install.
I want to share them with you because I want you to weep with joy just like I did.
Here are a few solutions:
Most of these work with a bunch of different languages and frameworks. This makes installing them a breeze.
They also work with many different tools like Slack, PagerDuty, Logstash, etc.. Which means you can receive notifications as soon as an error is reported.
What do they have to offer?
Obviously features will depend on the product you use, but overall they all aim to do one thing: give you as much visibility as possible into what went wrong and when.
For illustration purposes, I’m going to use screenshots mostly from Rollbar.
This is a section from the main dashboard which shows you all the exceptions have happened in the last 24 hours, and how many times they’ve happened.
As you see, there are multiple icons like a question mark, an ‘i’, and a triangle with a ‘!’. This is because you’re not just limited to reporting errors, you can also log helpful things. Something like:
Log::notify(‘Customer has pressed purchase button’)
Here’s another dashboard from Sentry:
Similar idea here.
Once you see an error, you can click on it to see details.
I created a scenario to show you. I created a registration form that uses an email API to send a welcome message. Only problem is that I used the wrong API key so my request gets rejected and the user is greeted with an error message.
As you see, this page shows us the stack trace. In this particular case, it’s an API that caused the error, but if it was from my code it would actually show which line of code threw the error. This is super helpful.
If we click one tab over to Occurrences, we can see how many times that specific error has happened, what time/date, and a bunch more information. Clicking on one of the occurrences will pull a new page with more details.
This screenshot only shows a fraction of what is given, but I chose it because it displays request.POST.email with the value testing@te.com.
This would be helpful in a number of scenarios.
- Testing data validation on a form
- Seeing how data changes through different layers of your app
- Debugging your form submission
- And a lot more, I’m sure
We can also replay the occurrence in browser or with a curl command.
This is just a fraction of features available. Take a look at the available tabs in the screenshot above that show the stack trace.
Error reporting is not just for development! You can also use it in production and monitor it a few times a day. That way you know exactly when one of your users or customers runs into an error.
This serves two purposes:
- Increases confidence when deploying
- Gives you a chance to correct mistakes before they cause too much damage
I hope this article has taught you something that will save you hours of debugging. I know how frustrating it is, and I wish someone had introduced me to solutions like these a long time ago.
Happy debugging my friends!
Have a great day.
If you found this useful, check out my blog and podcast for more. :)
