Some developers throw error logging into their applications simply because they feel they should. Almost like an obligation, as if by doing it they can add a tick to a check list somewhere and give themselves a pat on the back- go me! If this is your approach, then you might as well not bother – you’re doing it wrong.
Logging errors means nothing without having put some thought into what you plan to do with them. Whether they’re going to be delivered to your inbox, or written to a log file or database, you need to think about your strategy for dealing with them when they occur, and whether you plan to be proactive or reactive.
Emailing errors/exceptions is one of the more commonly used approaches for a proactive strategy. However it’s important to make sure that only the important “must fix” errors get sent out – sending every minor warning can lead to the recipient simply learning to ignore the noise, by adding a filter or simply switching off and becoming numb to the sea of errors and treating them as “normal”.
Thinking about your proactive strategy should force you to think about things which might occur where you’d want to know before the customer - the call to action should be clear – “we’ll want to look at this before our phone rings”. If you’re finding yourself flicking through error emails and continually not doing anything about their contents then you should revise your strategy accordingly.
We recently inherited a codebase which was diligently emailing errors - to the tune of around 30-50 a day. That’s simply too many to do anything meaningful with, and it quite clearly shows that either you have a serious problem with your application or with your error logging. As a result, that level of error mails was considered a baseline level of “normal” by the developers and the client, and was ignored just like the boy who cried wolf. 90% of what was being sent each day was due to a common and fixable issue which had never been addressed, meaning the remaining 10% which may have been worth looking into was hidden by a shroud of noise.
A reactive strategy is easier. Simply ensure you’re logging at a level which is going to allow you to work back and find out what was going on when you get that call/email from a customer. Presenting the user with an error ID from your application’s error page which references the logged entry when an error occurs is one way to achieve this.
Most strategies will involve a mix of being proactive and reactive. Email out the errors with high/fatal severities, and record the rest in case they’re needed. You can add proactive procedures to reactive logging by performing weekly/monthly reporting on your error logs - checking for your top recurring errors, and fixing them if possible.
All logging approaches should let you configure different severity levels for your events – for example, if you’re using log4net then you might like to read this post for some ideas. Make sure you use this in a way which is going to help you spend your time paying attention to things which need it, rather than letting important errors get lost in a sea of spam.
Next time you’re adding error logging to an application, stop for a minute and think about your strategy first – somewhere, someone’s inbox, and maybe even a customer may be very thankful.
Tags: You're doing it wrong