Logging is your friend. Trust the logger
Marcus Baker makes the claim that logging is evil. I cannot agree.
To be specific, he claims that "if there really is a chance of error at that point then we should fix the probable root cause." To me, this seems a wee bit lazy. As developers, we are paid to make careful decisions about how our time is best spent, and deciding to spend the time without considering the payoff is not a good idea. Put simply, there is rarely enough time to cover every possibility in our code. Were there, we would be using compilers mathematically proven to never generate incorrect code, and all projects would have zero defects, rather than just those under FDA certification and those running nuclear plants. That we live in a world with a fair amount of flaky software gives us some idea about how much quality is valued, as compared with time to market, functionality, or flash.
I can accept the argument that quality does sell, at least to some. I bought an Accord to replace my Saturn and the previous two T-birds, because I hate waiting for car repairs, and my experiences with American cars had not been stellar. American car quality has improved, but Honda still does a better job, so I paid more for a higher quality vehicle. By inference, there are buyers willing to pay for better software. The question then becomes how much are they willing to pay? Enough to justify completely bulletproof code? Enforcing pre, post, and operant conditions, which is effectively what Marcus asks for, is one way of enforcing quality, and an expensive one, just like adding complete unit test coverage to 50kloc.
To be clear - I like well tested code. Code with thorough unit tests suites is more likely to be of high quality than code without, because well tested code is often also code that has been well considered. Code with high coverage by the unit tests is less likely to end up in an untested condition, and thus is more likely to work because those edge cases have been thought about.
It also seems likely that a higher quality product leads to fewer sleepless nights. Certainly, I would rather get a call at noon asking me for a new feature than a call at 7pm asking why the server is down. Every developer I know focusses their testing and their thought on their guess as to the critical parts of the system. AS a corollary, every bug database has priorities in it, and pretending that all bugs are equally bad seems to miss the real social engineering implied by those priorities. Claiming that code with logs is "code that does not belong in your system" seems isomorphic to putting every potential bug at priority SEVERE and moving on.
Again, I doubt any developer decides "I think I will not properly test this code. Instead, I will log a developer lazy alert". Instead, we decide that certain failures should not happen if the rest of the system is put together properly. A log statement lets us test our assumptions in the real world. A concrete assumption can be tested easily - check the reference for null, or the array for at least a dozen elements. Complicated assumptions may well not be easy to articulate, let alone test, at development time, and, in fact, may not be testable at all until the program reaches the wild. A servlet I wrote recently logs the amount of time and total data pulled over from the dbms, as I have a sneaking suspicion that this will be important, but I am not able to put a quantifiable measure on that.
A concrete example: generated SQL is logged at FINE. The apps do not usually run at that level, but at least one critical app I have does. When users see slow response time, checking the log is up there with checking the server to get a quick idea of what the app is doing. Thus, without firing up a debugger, and without having to force the server to log all of the sql it processes, we get a pretty good idea of how the app is performing. It helps also to have the sql associated with why that particular query got performed.
In my experience, you do need standards about what is logged, how much, naming, and the like. Letting developers make a call without guidance does lead to Logs From Hell. Given a modicum of professionalism, appropriate buy-in and reasonable standards, logging can give you information that is hard to get in any other way. If nothing else, it is another cut on the state of mind of the developer, just like the unit tests that hopefully catch the errors you did anticipate.