Conditional Breakpoints: Stopping Only on the Run That Actually Matters

At a previous job, we had a batch job that processed customer records in a loop and failed on exactly one record out of several thousand, and only in production data, never in our test fixtures. Setting a normal breakpoint inside that loop and clicking Continue to get past the first few thousand harmless iterations was not a real option, so I finally set a condition on the breakpoint instead of babysitting it.

A conditional breakpoint only pauses execution when an expression you attach to it evaluates to true, so instead of stopping on every pass through a loop, it stops on the one pass you actually care about. In most debuggers, Chrome DevTools, VS Code, and IDE debuggers alike, you set this by right-clicking an existing breakpoint, or long-pressing it in the gutter, and entering a condition, such as i === 4000 or record.id === 'A1938', instead of just placing a plain red dot.

This is different from a plain breakpoint hit count, though some debuggers let you set both: a condition evaluates arbitrary code in scope at that point, so you can check something more specific than a loop counter, like customer.balance < 0 or response.status >= 500, and only pause when that state actually shows up. That is what found my batch job bug -- the condition was on a field being unexpectedly null, not on the loop index, since I did not actually know it would be the four-thousandth record until the condition told me.

The practical win is time: without a condition, finding a bug on iteration 4,000 means either clicking Continue thousands of times or adding a manual counter and an if-statement to your source code, running it, then remembering to remove that debug code afterward. A conditional breakpoint does the same job without touching the source, and you can delete or disable it the moment you are done, leaving no debug code behind to accidentally ship.