Interactive Debugging vs Logging
February 13th, 2006I do not like to use the debugger very often. Instead I use logging, typically log4net to append dated notes to a log file which I can monitor all the time without a debugger. And I can even leave the logging statements in the code when the software is pushed to staging and production systems. I simply have the configuration set to log only the important messages outside of the development environment. The log4net utility has 5 default leaves: DEBUG, INFO, WARN, ERROR and FATAL. If I am handling an exception I will flag the message with WARN or above depending on the nature of the exception. But most of the time my logging statements will reveal useful information that give me some insight into the internals of the software. Instead of placing a variable into a Watch in the Debugger I can simply log the name of the variable and whatever Properties I want to see.
Sometimes it helps to run the debugger to see which path a process will take when I cannot explain the behavior by reading the code, but it is often faster to simply add a logger statement, recompile and run the software. But you have to keep monitoring the log. Opening a text file over and over can become tedious. Fortunately I can use Tail for Win32 which allows me to monitor a text file for changes and it immediately shows the changes, just like the tail -f error_log I use with a Unix system.
My first few years of software development were done with Perl/CGI on a Unix system and I would monitor the internals of a Perl script with the error log. I simply printed to STDERR. I became quite comfortable with that mode of debugging. I suppose that is why I do not jump into the interactive debuggers all that much. After a while I found that I no longer had to bother with logging as I understood what was happening when an error happened and was able to correct the problem without looking at the error log. My take is that you should understand the software implicitly so that you will understand where the error happened when it happens. And if the software is too complex to understand by reading the code, then it is time to do a little refactoring.
