What’s your logging philosophy?

Question

As Jeff Atwood asked: "What’s your logging philosophy? Should all code be littered with .logthis() and .logthat() calls? Or do you inject logging after the fact somehow?"

Answer 1

If you really need logging in your system then your tests are crap or at the very least incomplete and not very thorough. Everything in your system should be a black box as much as possible. Notice how core classes like String dont need logging - the primary reason being they are very well tested and perform as detailed. No surprises.

Answer 2

I start by asserting a lot of conditions in my code (in C#, using System.Diagnostics.Assert), but I add logging only where I find, while debugging or putting the system under stress, that I really need to have a way to follow what's happening inside of my code without having a debugger permanently attached.

Otherwise, I prefer using Visual Studio's capability to put traces in the code as special breakpoints (i.e. you insert a breakpoint and right-click it, then select "When hit..." and tell it what to display in that case). There is no need to recompile and it is easy to enable/disable the traces on the fly.

Answer 3

Log 'em all and let Grep sort 'em out.

Answer 4

I think always, always, always add logging when there is an exception, including the message and full stack trace. Beyond that, I think it's pretty subjective to whether or not you use the logs often or not...

I often try to only add logging in critical places where what I am logging should very rarely hit, otherwise you get the problem like he mentioned of logs that grow way too big... this is why logging error cases is the ideal thing to always log (and it's great to be able to see when these error cases are actually being hit so you can inspect the problem further).

Other good things to log are if you have assertions, and your assertions fail, then log it... such as, this query should be under 10 results, if it is bigger there may be a problem, so log it. Of course, if a log statement ends up filling the logs, it is probably a hint to either put it to some sort of "debug" level, or to adjust or remove the log statement. If the logs grow too big, you will often end up ignoring them.

Answer 5

I choose to log deliberately as I go, as this means the log data is meaningful:

• Depending on logging framework you can add level/severity/category information so that the log data can be filtered
• You can make sure that the right level of information is present, not too much, not too little
• You know when writing the code which the most important things are, and can therefore ensure they are logged

Using some form of code injection, profiling or tracing tool to generate logs would most likely generate verbose, less useful logs that would be harder to dive into. They may be useful as a debugging aid, however.

Answer 6

I define a variety of levels and pass in a setting with the config / invocation.