“The young man knows the rules, but the old man knows the exceptions.” - Oliver Wendell Holmes, Sr.

And the wise developer knows their application’s exceptions.

Ideally your software will run perfectly without any bugs - ever! In practice this is unlikely. The level of engineering effort required to get truly bug free software is _obscene _relative to most business use cases; for non-trivial software it requires the kind of budget that can send a space shuttle into orbit[1]. So we should just shrug at bugs?

No! But whether you’re a developer or a project owner you need to adjust your expectations and know that you will encounter new bugs, and that means you need to know how to find them so you can resolve them. So sometime around or after you get your database backups running and tested, you’ll want to make sure you have a strategy for understanding the 

There are, grossly speaking, two kinds of bugs: logic errors and exceptions. The former are the kind that result in _the wrong output, _e.g. telling the user that 2 + 2 = 5. The latter result in the application throwing an exception, e.g. trying to parse Unicode characters in a byte string (hello Python 2!). While the latter may have more catastrophic results like a 500 error preventing your own customers from doing anything, they are easier to identify.

Ah, you say, using the Django error emails that we quietly delete, you mean? Well, you’re on the right track…

It’s nice that Django provides an immediately configured way to alert you of exceptions on your site, but the exception emails are an unwieldy and insufficient way of handling these errors. Not only can they result in a flooded inbox, they provide no good way of sharing with a team, don’t allow linking to a resolution system, have no error history, and most poignantly the data you get isn’t even that good. A far better solution is to use a dedicated exception tracking system.

Our own preference, for internal applications and customer applications alike, is to use Sentry[2] but you can use other services[3] just as well. Sentry works as part of your logging system to intake all exception data, including much richer stacktraces that show application context at each step in the stack, and also logged errors. Imagine having the full dev server stacktrace (like in the image above) even for production errors. We truly are living in the future.

Adding error tracking to any legacy application is one of the first steps in establishing a baseline of application safety. If you’ve gone through our Django Tune Up email course this is mostly old hat, if not you can check it out by clicking this link.

Until our next episode,
Ben

[1] This article from FastCompany describes the software for the now defunct space shuttle: “This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.”
[2] Sentry (not an affiliate link)
[3] Rollbar, Airbrake
 

More like this

• This Old Pony: to CBV or not to CBV
• The Old Pony: But first the backups, or losing data