3 ms·
It's weird to read a whole article about debugging that doesn't discuss debuggers. "Use a debugger," it says, offhandedly, as if you already know how to do that
by dfabulich 7y ago
It's weird to read a whole article about debugging that doesn't discuss debuggers. "Use a debugger," it says, offhandedly, as if you already know how to do that. But the sort of person who needs this article almost certainly doesn't know how to use a debugger.
Debuggers have a mixed reputation on HN ("I never use a debugger; logging statements are way better") but IME too many developers, especially ones fresh out of school, literally have no idea how to set a breakpoint and step in/out.
For those who do know how to set a breakpoint, that's typically all they know (and so they assume that debuggers aren't very useful); they don't know how to drop ("restart") stack frames, run arbitrary code in the debugged process, set conditional breakpoints, ignore ("blackbox") files, debug remote processes, edit the in-process code without restarting, etc. etc. etc.
Every developer working on code mostly written by other people should learn how to use their debugger's tools thoroughly.
- rhinoceraptor 7y agoI'd put tracing tools (dtrace, eBPF, etc.) in the same category. Many bugs only happen in production, and you can't run a debugger. The might also be triggered in some way such that they don't happen when stepping through code, for example race conditions or network faults.