Trace, Trace, Trace, and Trace

[Previous] [Next]

Assertions might be the best proactive programming trick you can learn, but trace statements, if used correctly with assertions, will truly allow you to debug your application without the debugger. Like assertions, TRACE macros for C and C++, and Debug.Print for Visual Basic, go away in release compiles, so you can use as many as you want. For some of you old hands out there, trace statements are essentially printf-style debugging. You should never underestimate the power of printf-style debugging because that's how most applications were debugged before interactive debuggers were invented.

Deciding how much to trace has always been a problem, especially if you're working on a team of more than one person. If everyone traces just a little, the volume of trace statements can quickly become overwhelming. At a minimum, key data structures and paths through the code should have trace statements associated with them. However, because trace statements are so useful, I've made it easy for you to put as many trace statements in your application as you'd like. The LIMODS (Limit OutputDebugString) program that's the topic of Chapter 14 allows you to limit the trace statements to only the source files you're interested in seeing.

Although trace statements can solve almost all your problems, they have two drawbacks. Neither limitation is serious enough to prevent you from using trace statements, but you do need to keep in mind the issues that can arise when you use them.

The first limitation is that trace statements usually cause your application to serialize execution when you call them. This means that your high-speed multithreaded application can perform in a completely different way when you use trace statements because the threads block and are scheduled around the trace statements. If you properly developed your multithreading code, as I describe in Chapter 12, you shouldn't have any problems. However, I've seen cases in which code that works inside the debugger or with lots of trace statements doesn't run outside the debugger or in release mode.

The second limitation is that, because of the serialization problem, too many trace statements can make your debug build run very slowly. If you encounter this problem, you're trying to trace too much and you need to cut back. For example, always avoid putting trace statements inside tight loops.

When you're planning your tracing strategy, your team should spend some time thinking about how to format trace statements. If everyone uses a similar format, finding information with grep or writing simple parsers to analyze the logs is easy. I prefer to follow the format "function : trace statement." By starting with the function name, I can easily grep just for the functions I want to see. Be careful not to get too complicated with the format. If you make the format too complex, developers won't remember it and therefore won't use it.

Normally, you see trace statements only in the debugger Output window. However, a must-have free utility, DebugView/Enterprise Edition from Mark Russinovich at www.sysinternals.com, allows you to see your trace statements as your application runs outside the debugger. I run DebugView/Enterprise Edition all the time. Because I can see my trace statements, I can see what's happening in my applications. DebugView/Enterprise Edition is especially helpful when you're working on multiprocess COM applications because you can see all the cross-process interaction in one place. Another area in which DebugView/Enterprise Edition is a huge help is with those COM applications that run in contexts that you might not control, such as Microsoft Internet Information Services (IIS).