Dan Lebrero on April 18, 2017

This article originally appeared on IG's blog So you just wrote another try/catch block and again you start wondering: should I log this excepti... [Read Full]
markdown guide

As someone who has often wondered which one to use, I like the spin this puts on logging and it makes a lot of sense. The old logging method names don't really convey intent like we've been taught to do for so long. I dig this. Thanks for sharing.


Glad you liked it. You will probably find Steve Freeman Logging is also a feature interesting.


It's good to have concrete definitions of what the error levels mean. It's also nice to eliminate as much as possible from live logs.

On a previous project we defined "Error" the same way, but we defined "Warning" a bit differently. We said that warnings are conditions are conditions that if they occur sometimes are okay, but if start appearing frequently, or too many at a time, are a problem.

We used those to mark code paths that were inefficient, or fallbacks to preferred algorithms. Something we'd expect to come up a couple of a times of day due to the operating environment. If they happened often it meant they were causing a significant problem for the tool.


Thanks for the comments.

We have toyed with the idea of adding a "wakeMeIfThisHappensTooOften" method to the logger to cater for that use case. The hard question is what means "too often".

In practice we have found that most times the places have this use case are protected by a circuit breaker so monitoring the circuit breaker is enough.

I would avoid having that couple of alerts every day if they are systematically ignored. One day they are two, next day they are four, ... One of the last projects that I worked at ended up with 13000 of those alerts which prompted me to write this blog post

code of conduct - report abuse