Logging Strategies

---

Before I discuss particular tools for logging application activity, I’m going to take a look at the general idea of logging. If you’ve never set up comprehensive logging for an application before, you might not be sure what this entails. The basic idea is simple: An application log is designed to provide a permanent record of activity within the application. The log might be saved to a text file, a database, or even an instant messenger session. The important thing is that the log provide the clues that you need to tell what happened while the application was running—particularly if something went wrong.

Logging during Development

Logging is typically not all that critical during development. That’s because as the developer you have the comparative luxury to drop into the debugger when something goes wrong, so you may not have to analyze crashes based on the application’s history. Yet there are still some circumstances where maintaining a log can be important:

• When internal testers are working with your application, a log can help you understand the actions that led to a particular bug.

• If the application depends on asynchronous input (such as financial data from an external web service, or events from an analog-to-digital converter), a log can help clarify the order of events.

• Some bugs only manifest themselves when the application isn’t running in the debugger. For those bugs, a log can provide vital clues.

• Some bugs may occur only after hundreds or thousands of calls to a particular function. In such a case, it can be helpful to log what’s happened during an automated testing run so you can look for patterns.

The basic goal of logging during development is to collect information that you can’t get by running the code in the debugger.

Logging after Shipping

Logging is usually more useful after the product has actually shipped to end users. Generally speaking, you can’t trust the ultimate users of an application to write a good bug report. (See Chapter 9, “Tracking and Squashing Bugs,” for a discussion of good bug reports.) It’s much easier to ask them to submit the log along with their description of the problem.

When the application is with end users, though, you need to pay attention to the potential overhead of logging. Depending on the amount of information you save and the form that you save it in, this overhead can be substantial. This leads to a simple rule:

RULE

In a shipping application, it should be easy to turn logging on and off.

Rather than implement continuous logging at all times, you need to implement a scheme that lets the end user turn logging on, perhaps by editing an XML file or a Registry key. That way, the logging code can be dormant and not affect application performance until it’s really needed. Typically, you or (if you’re lucky) your customer support staff will instruct the end user to turn on logging, re-create the problem, send you the log, and then turn logging back off.

When you do turn logging on in a shipping application, what should you log? Here are some ideas:

• Error messages and information, including a stack trace of the error

• The state of internal data structures at key points in the application

• User actions, such as button clicks and menu item selections

• The time that significant actions were performed

• Important information about the environment, such as variable settings and available memory

In general, you want to make sure that the application log includes enough clues that you can tell what went wrong when something goes wrong. If you think about how you debug your application when it’s running on your computer, you should be able to come up with a good list of information to log.

RULE

Log the information that you use when debugging.

---