It blows my mind how often i see people using temp logs for debugging when breakpoints exist
When the issue is only seen after hours of runtime, logging is more practical.
I recently had an issue that happens on one out of between ten thousand and a hundred thousand interactions between two embedded processors. Thank god for logging!
Even logging can sometimes be enough to hide the heisgenbug.
Logging to a file descriptor can sometimes be avoided by logging to memory (which for crash-safety includes the possibility of an mmap'ed file, since the kernel will just take care of them as long as the whole system doesn't go down). But logging from every thread to a single section of memory can also be problematic (even without mutexes, atomics can be expensive and certainly have side-effects) - sometimes you need a separate per-thread log, and combine in the log-reader tool.
Well, conditional breakpoints exist.
But use whatever is easiest. People trying to micromanage how others use computers are the worst. And on the most popular languages by job count, your debuggers isn't all that more powerful than a well-constructed log anyway. (Hell, the people insisting that others adopt better tools should start with the language.)
Or when the overhead of the debugger causes the issue to never happen
Idk... I had problems in the past with weird bugs where the breakpoints do not match the right line although using sourcemaps and all that so sometimes you end up doing stuff like this.
Or if you want to know how many times something executes without well having to "continue" on each breakpoint or similar.
It blows my mind how often i see people using temp logs for debugging when breakpoints exist
When the issue is only seen after hours of runtime, logging is more practical.
I recently had an issue that happens on one out of between ten thousand and a hundred thousand interactions between two embedded processors. Thank god for logging!
Even logging can sometimes be enough to hide the heisgenbug.
Logging to a file descriptor can sometimes be avoided by logging to memory (which for crash-safety includes the possibility of an mmap'ed file, since the kernel will just take care of them as long as the whole system doesn't go down). But logging from every thread to a single section of memory can also be problematic (even without mutexes, atomics can be expensive and certainly have side-effects) - sometimes you need a separate per-thread log, and combine in the log-reader tool.
Well, conditional breakpoints exist.
But use whatever is easiest. People trying to micromanage how others use computers are the worst. And on the most popular languages by job count, your debuggers isn't all that more powerful than a well-constructed log anyway. (Hell, the people insisting that others adopt better tools should start with the language.)
Or when the overhead of the debugger causes the issue to never happen
Idk... I had problems in the past with weird bugs where the breakpoints do not match the right line although using sourcemaps and all that so sometimes you end up doing stuff like this. Or if you want to know how many times something executes without well having to "continue" on each breakpoint or similar.