Breakpoints: Pausing Time

Debugging isn't about staring at code trying to imagine what it does — it's about actually pausing your program mid-run and looking at what's really happening. Breakpoints are how you pause it.

Click in the left margin next to a line to set a breakpoint — a red dot appears, and that line gets a red highlight. When you run with F5 (Start Debugging, not Ctrl+F5), your program runs normally until it reaches that line, then pauses completely — variables frozen, nothing executing, waiting for you.

Conditional breakpoints only pause when something specific is true. Right-click a breakpoint's red dot → Conditions — set an expression like i == 5 or user == null, and the breakpoint only triggers when that's true. Essential for a bug that only happens on the 500th loop iteration, not the first.

Once paused, you have four ways to keep going:

• Continue (F5) — run until the next breakpoint or the program ends.
• Step Over (F10) — execute the current line and move to the next one, without diving into any method calls on that line.
• Step Into (F11) — if the current line calls a method, jump inside that method and pause on its first line.
• Step Out (Shift+F11) — finish executing the current method and pause right after it returns to its caller.

The yellow arrow shows exactly where you are. While paused, a yellow arrow in the left margin marks the exact next line about to execute — this is the single most important visual cue in the debugger.

Why this matters for you

The difference between "I think the bug is around here" and "I watched the exact line where the value became wrong" is breakpoints. Everything else in this course builds on that pause.

▶️ Before the next lesson

Set a breakpoint on any line in your project that runs when you start it, then press F5. Confirm you see the yellow arrow and the program genuinely paused — that's the whole mechanic working.