Selfelected

Why I try to not use the debugger

Readable logs

In production we usually rely on logs to track down an error.
Even worse; in production we have more data and more logging to sift through than in development. The trees can be lost in the woods. If we are more unlucky we also have a time restraint.

To learn how to read a log file we must train. This means reading log files. And to read the we must first write to them; in a readable way.

So I write log files and read them to find my errors already in development. Training for production.

Learn to write

Too little information is bad. This is the usual case. Too much information is bad too as we cannot see the flow of the program due to uninteresting information. Writing the exact amount of information for every time is probably not doable but by training I learn and get better at it.

Readable code

If we develop the application through setting breakpoints and inspecting variables we are in a bad spot when production error happens as we seldom can do that.
All we have is a log with a stack and possibly a rough idea of the input.

If I instead learn to read the code and trace the execution path manually, already in the development phase, I am in a much better position when production hits the proverbial fan.

Startup time

Connecting the debugger takes time. Just starting the program is faster.

I only connect the debugger when I have to.

Wrap the logging framework

If you haven’t decided whether to use Log4Net, EnterpriseLibrary, nLog, home baked or any of the other logging frameworks – wrap it or abstract it.

Common.Logging is an “ordinary compiled lib”. It is strongly named with its pros and cons.

LibLog on the other hand is just a file (like Dapper). When developing a lib for public use this might be good to keep fewer dependencies.
The author of LibLog mentioned some pros for LibLog (vs Common.Logging) here. It uses dynamic and Tuple so it is Dotnet4+.

Simple Logging Façade is a compile lib, like Common.Logging.

Logging WCF

If you have a WCF solution it is quite easy to log the calls.  (probably not always but it worked for me)

I used http://stackoverflow.com/questions/9232819/wcf-tracing-seems-to-be-truncating and http://msdn.microsoft.com/en-us/library/ms730064.aspx as info.