Debugger or print? That is the question

I've used printf (or equivalent) more often than I've used a debugger but sometimes a debugger is the right way to find a problem. For example, you mention an "error message", but I've occasionally had situations in which a process running a binary built from a large code base that I have never even looked at (though I do have the source) dies for no obvious reason and with no useful output, but I've been able to restart everything, attach a debugger, and then, when it dies again, with great luck get enough information from the debugger to fix the bug faster than it would take to rebuild everything let alone insert printfs everywhere where they might help. Usually that's been in cases where I know roughly the sort of thing I'm looking for because I know the main differences between the system it's failing on and the systems it used to work on, though I have absolutely no idea where that sort of thing might be in the code that I've never looked at. If I'm running code I've just written myself I usually find I have no use for a debugger.

The best thing about a debugger is that it works without any modification to the code. Prints and other debugging hacks sometimes get checked into version control and even if you are careful to avoid that the cognitive load slows you down.<p>That said there are certain things that confound debuggers or require technical tricks (like the method for debugging Java&#x2F;C apps with both jdb and gdb which requires turning off the segfault trap). If the key to solving the problem involves understanding the sequence of events, or where the problem turns up when the breakpoint has been hit for the 74532th time prints win too.<p>Do you use a language with a logging facility? Learn how to use it and improve your skills.<p>In Java I use the debugger and unit tests a bit like I use the REPL in Python, that is I can code up an experiment in a unit test and rapidly cycle and experiment, and the great thing is I have a unit test that I can check in when I am done.

I&#x27;m assuming you mean a software-only debugger, and I mostly feel the same way as you. The process of starting the debugger, setting breakpoints, etc. feels a lot like going to the doctor when you&#x27;re sick rather than self-diagnosing, which works great 90% of the time and doesn&#x27;t involve getting into the car and lots of waiting.<p>I could see a strong use for things like multithreading, profiling, seeing a list of variables&#x2F;values that are in-scope at a breakpoint. The more complex the software, the more useful...<p>The last time I needed a software debugger, a tool I was using would communicate with another by sending its PID as an ID. Problem? The tool thought the PID fit in a 16-bit, so it was sending a totally bogus number. I probably would have found this eventually, but with the debugger, it was as easy as &quot;Why is the sent PID 39283 instead of 170355?&quot; This only occurs after Windows has been on for several weeks and enough conhost&#x2F;svchost&#x2F;wslhost processes push new PIDs above 65535.<p>Humorously, such a bug goes away when you &quot;turn the PC off and on again&quot;<p>-----<p>Hardware debuggers (for microcontrollers) often have a whole host of benefits that are immediately obvious once you involve any physical I&#x2F;O. Also, they&#x27;re vital for things like event logging (for Arm, PMU events flag for cache misses, branch events, operation stalls, and much more) or seeing what&#x27;s happening with an off-chip device, peripheral, other cores, anything to do with watchdogs, etc.<p>Writing something like impact failure handlers for a drive head controller for a hard drive, you&#x27;ll want to be able to set an external trigger as soon as the failure is initiated, connect that to your debugger via one of its trigger-detecting inputs, and then you can capture the real-time data and execution traces and move back to the exact moment the failure occurred, how your variables changed, and what exactly the failure handler did to ensure the drive head attempted to park as soon as possible. In short, this is not printf-able, but it is also an extreme example.

Learn how to use a debugger. It sounds like the code base you’re working on a small enough that print statements are fine, but that won’t always be the case.<p>Imagine you’re working on a bug that’s extremely hard to reproduce (say, a race condition), takes a lot of time to reproduce (maybe at the bottom of a long running function), or is somewhere you can’t easily access (a remote device). Your print statement shows that $foo is -1, which doesn’t make sense. Better check what $bar is. So you now have to rerun the program, only to see $bar prints “???????” because for some reason it’s bytes but you’re printing it as UTF8. So now you have to modify and rerun your program to print out the hex values to figure out if there’s any meaning to them.<p>Congrats, you spent an hour getting three pieces of information.<p>If you just set a breakpoint, you can go for lunch and come back to a paused program where you can check the state, display information and data structures in whatever way you’d like, and proceed one step at a time to see what happens at each line of your code.

You&#x27;re only doing something wrong if you&#x27;re failing to get your work done. The important part of the debugging process is the bit that happens in your head, so you should use whichever tools suit the way you think.<p>It depends somewhat on the type of work you are doing. Some problems are more easily spotted by dropping in and having a look at the program state, but there are problems a debugger cannot help you with at all.<p>I made heavy use of debuggers earlier in my career, but after a few years working in environments where logging was the only option, I found I preferred that style.

I think print debugging is great, but if all of your colleagues use a debugger, you might work in a context where that&#x27;s a useful superpower.<p>You actually have an opportunity to learn how to use a debugger well right now and you should probably take it.<p>Once you learn how to use it well, you can make an informed decision on if it&#x27;s actually better.

I&#x27;ll use a debugger sometimes when the error is getting thrown in code I don&#x27;t control but can view the source of - it can help figure out context and what the external code is doing. Otherwise I normally just put print statements for things I&#x27;m unsure of and remove them before committing.

I&#x27;ve interviewed folk who say they don&#x27;t use debuggers. They usually don&#x27;t get the job.

You are doing something wrong. There are huge productivity benefits in learning how to use a debugger effectively. Debuggers have benefits that go beyond just fixing known defects. I have disciplined myself to step through every line of code that I write while watching the control flow and state changes. This allows me to proactively find and resolve defects and inefficiencies that would have otherwise leaked through testing. Issues that you would never notice while reading source code or looking at print statement output become much more obvious in a good debugger.