|
|
| Note |
Why is this process called "printf debugging" instead of something more logical like "print debugging"? Printf (short for print formatted) was the primary I/O function in the C language, and the name stuck. |
The biggest annoyance of printf debugging was that every time you wanted a new piece of information, you had to add another print statement and recompile. And you'd have to make sure you added all the print statements you needed the first time, because recompiles were expensive. Complex bugs sometimes took a dozen recompiles or more, and think of all the wasted time. That was all we had back before debuggers were widespread, and no developer would ever want to go back to that. But even though we no longer use printf debugging (henceforth called "logging") to solve routine bugs, it's still a big aid with other types of bugs.
Take multithreaded programs, for instance. Sure, the VS.NET debugger supports debugging multiple threads at once…. just like a two-person rowboat theoretically supports transatlantic crossings. But have you ever tried it? The mere fact that your multithreaded program is running in a debugger at all will alter its behavior. The thread you watch in the debugger will proceed much slower than normal, so a deadlock that readily occurs when the program is run at full speed might not show up at all when debugging.
But if the debugger can't reproduce your multithreaded bug, try adding a few strategically placed print statements to say "Thread 1 now doing such-and-such", "Thread 2 now doing thus-and-so", and you might have a better shot at tracking down the bug. At the end of the program execution, read the output log and you'll know what one thread was doing when the other thread messed up.
That's just an example, though. Logging will solve some types of bugs more easily than the debugger, but for most bugs, the debugger has an edge. Where logging really pays off is when using the debugger isn't even an option. Since you usually can't attach your debugger to a process running on a customer's production machine on the other side of the country, program logs are your most effective technique for debugging issues at customer sites.
|
|