Actually, it’s more than good, logging is essential in any application. We wasted a whole load of time today because we weren’t using our standard logging framework (log4net), and the basic logging that was implemented was throwing an error that was effectively swallowed – result – extremely hard to debug errors.
One of our users, reported that his spreadsheet wasn’t working correctly. This sheet connects to an application server via a magical mixture of COM, RTD and remoting. All we got was a mysterious error message from his client dll in our logs telling us to enable custom errors in the service config file. In case you are wondering, this didn’t work, you need to enable custom errors with the code:
RemotingConfiguration.CustomErrorsMode = CustomErrorsMode.Off;
So, errors received from the server to the client were now more useful. We then had the nice issue of logging not working on the server. We spend some time enabling log4net on the server dll, and voilla, proper debug info.
We could now see that our legacy exception handler was itself throwing an exception due to some string manipulation that wasn’t having it’s boundaries checked.
By the end of the day, we completed a unit test to fix the original bug, plans to create a build script for the server side dlls, and logging introduced throughout the remoting solution, client and server. Frustrating, but ultimately rewarding.