3 ms·
well it's hard to find a race condition with a debugger. sometimes it would just work with the debugger since you slow down the program or maybe halt on the wro
by merb 8y ago
well it's hard to find a race condition with a debugger.
sometimes it would just work with the debugger since you slow down the program or maybe halt on the wrong places.
- teh_klev 8y agoSure, but I'd argue that most developers aren't working with code day in and day out where race conditions are a concern.
- merb 8y agowell it depends, I mostly try to create my code so that things can run in parallel. I also barley use a debugger, even for code that does not run in parallel, mostly because I'm used to make logging calls at the right places so that I can find issues way faster than with a debugger (most often I'm only run into hard issues or issues where a debugger will fail, i.e. build scripts -_-)
- singlow 8y agoThe point is that the debugger is an essential tool for debugging because in most cases it will do what you want and is faster. Most coding errors are not race conditions. I don't know why everyone must pipe in with the edge cases where a debugger might not work. In 99% of scenarios where you want to test some code in a development environment, setting breakpoint is the quickest way to see what is wrong. Log output is useful too, and you will probably use both. But, if you are a developer and don't have the ability to step through your code in a debugger, many problems will take much longer to fix.