3 ms·

Try debug a racing issue with debugger. If you use it, issue dissapears, if you don't issue it's there. Using print is a sign tooling isn't up for the task. No

• whynotminot 4y ago
  > Using print is a sign tooling isn't up for the task. Not necessarily inexperience. This. For application developers, if your users aren't taking advantage of features in your software, it's a sign the features either aren't actually better, or aren't intuitive enough to gain traction. It's a tell that you still have work to do. I don't see why the same arguments wouldn't also apply to tools for developers like debuggers. Just because your userbase is more technically savvy doesn't mean you shouldn't care about ease of use.
• kaba0 4y ago
  A print will quite often make the race issue disappear as well (due to it being synced in many cases). The JVM’s flight recorder may be a better option to fight such an issue.
  • brabel 4y ago
    Try an asynchronous logger in that case.
• strictfp 4y ago
  A debugger can work in many ways, it can also print, or trigger on altered memory. I would say that a debugger is generally more useful for finding race conditions than logging. But writing tests is really the best tool there. In my opinion printing or logging is much more useful than debugging when you want to be able to understand the sequence of events leading up to a bug, where the debugger isn't very strong. After analyzing the logs, using conditional breakpoints depending on each other can help you catch the issue live. Each tool has their strength and weakness, but I would never go so far as to say that debuggers are pointless. Being able to inspect memory and browse for inconsistencies can be priceless.