There are two reasons that I’m using log4net with increasing, rather than decreasing frequency, despite the excellent debugger in VS.NET:
- When doing multithreaded programming, it lets me more easily see what threads are doing in parallel
- Heisenberg’s Uncertainty Principle as it it relates to Properties
Let me expand on 2)… The Uncertainly Principle, simply put, states that the act of observation changes the observed. Now, he was talking about electrons, but when using the debugger in VS.NET this very principle can really come to bite you. The problem is that Properties do not have to be mere member variable accessors. They can have all sorts of logic attached. You may consider it bad form to have the act of observation (read: the getter) enact some sort of write behavior, and that is a position worth arguing. But even a simple “lazy load” put inside a getter can alter the behavior of the object if executed outside the normal flow.
And that’s precisely what happens when you start stepping into the Debugger. Unlike Methods, Properties are shown by default and therefore cause execution of the getter. So if you have a problem with some internal value not being properly set when you run your program, but it being set, if you step through it, look at your Properties.
Now, how does log4net help this? It’s still going to cause the getter to fire! Well, in some circumstances yes, but in many others, the reason you are getting this behavior is because the debugger fires all getters, not just the ones you want to look at, likely causing the problem via some part of code you really don’t want to be firing off at the time of observation.