3 ms·

Thanks for saving me the trouble of writing this post. ;-) I'll just add this: once you get to Step 3, conditional breakpoints are your best friend. Sometimes

Thanks for saving me the trouble of writing this post. ;-) I'll just add this: once you get to Step 3, conditional breakpoints are your best friend. Sometimes they're too time-consuming and you have to resort to manually "instrumenting" the code to get the conditional breakpoint, but the principle is the same.

AstralStorm 10y ago
And all bets are off when considering realtime behaviour such as concurrency or fairness. Neither debugger nor logs will help (they change behaviour and reproducibility is low) so you have to get to the basics and make a formal review. As in describe the expected algorithm, its preconditions, postconditions and then verify if this contract is met.
- TimJYoung 10y ago
  Yep, know it well, there's a whole class of applications that don't play well with a debugger. But, most developers aren't working on those applications...
  - AstralStorm 10y ago
    Most developers do not worl on user facing concurrent code? Such as user interfaces?
    - TimJYoung 10y ago
      No, not normally. It's fairly rare, and when it does crop up, it is typically handled with pre-baked solutions that are used to spawn a worker thread/process for the purposes of off-loading work from the main UI thread, with minimal communication with the main UI thread via posted messages.