|
|
|
|
|
|
by Delk
1406 days ago
|
|
|
> When build times are short, spinning up a debugger is overkill compared to adding a couple of debug statements. I often find it a lot faster to set up breakpoints and fire up the debugger than to write debug statements. At least in some IDEs, breakpoints are a single click each, and if you have to restart the application/module/whatever anyway, doing that in a debugger instead of a non-debug run is also just a click. I can then inspect any variable values at the breakpoint instead of having to explicitly include all potentially interesting ones in the debug output. When I'm trying to figure out a problem in code I'm writing rather than one in production, the debugger is often my first resort. I'm mostly writing plain old backend code without asynchronicity, though. Debug output (at a reasonable level) is still useful even outside of asynchronous program flow, of course, because it might give immediate clues for problems encountered in testing or production. If you don't have a good idea of where to look, debug output from several places might also be nicer than having the program stop at lots of breakpoints that turn out to not be useful. |
|
|
I have the exact opposite opinion. Firing up the debugger is what you do when you no longer know where to look, because you need it to examine the whole program state and have the ability to step through. Writing a console log with output from a variable is the precise "I already know what the problem is, all I'm doing is verifying it" approach.
> if you have to restart the application/module/whatever anyway, doing that in a debugger instead of a non-debug run is also just a click
A click that spawns a process that takes 10x longer to spin up. Debuggers are slow and heavy.