Conditional Breakpoints and Logpoints

The basic breakpoint from the Debugging course stops execution every time a line runs. Real debugging often needs something more targeted — stop only when it matters, or don't stop at all.

A conditional breakpoint stops only when an expression evaluates true. Right-click a breakpoint's red dot → "Edit Breakpoint" → enter a condition like i === 47 or user.role === "admin". In a loop running thousands of times, this is the difference between stepping through manually until the interesting iteration and landing on it directly.

A hit count condition stops after N hits, not on a boolean. Useful for "this runs constantly, but I only care about the 3rd time it happens" — set the condition to hit count instead of expression, and specify the number.

A logpoint prints a message to the Debug Console without stopping execution at all. Right-click in the gutter → "Add Logpoint" → write a message that can embed expressions in {curly braces}, e.g. user id: {user.id}, role: {user.role}. This replaces temporary console.log statements entirely — same information, zero code changes, and trivially removed by just deleting the logpoint.

Logpoints show as diamond-shaped gutter markers, visually distinct from the solid red circle of a real breakpoint — easy to tell at a glance which lines actually pause execution and which just report.

Why this matters for you

Conditional breakpoints and logpoints turn "step through this 500 times to find the one bad iteration" into "stop exactly where the problem is" — the same debugger, used with much more precision.

▶️ Before the next lesson

Find a loop or frequently-called function in a real project. Add a conditional breakpoint or logpoint to it, and confirm it only fires (or only stops) under the condition you specified.