Breakpoints & Stepping

Pause at the interesting line

A breakpoint tells the browser to stop JavaScript before it runs a chosen line. Open DevTools, go to Sources, find the relevant file, then click the line number to set a breakpoint. Reproduce the interaction and execution pauses when it reaches that point. This is more useful than guessing because you can inspect the program at the exact moment its state matters.

For your planted-bug quest, choose a line near the suspicious calculation or state change. If the line is never reached, that is evidence too: the event may not be wired, or an earlier condition may prevent the code from running.

Inspect state while paused

While execution is paused, inspect local variables and the current call stack in DevTools. The Scope area shows values available at that point. Compare what you expected with what the program actually has: an unexpected string, missing object property or empty array can reveal the bug.

The debugger; statement is another way to pause execution when DevTools is open. It acts like a breakpoint written in code, and should normally be removed after debugging so it does not interrupt users.

Step through the code

Use the stepping controls to move through execution deliberately. Step over runs the current line and pauses at the next line in the same function. Step into follows a function call into that function’s body. Use step into when the called function may contain the fault; use step over when you only need its result.

function addBonus(xp, bonus) {
  const total = xp + bonus;
  return total;
}
const result = addBonus(40, 10);

Pause on the call to inspect inputs, then step into to check how the total is formed. The small example shows the kind of state you can observe, not a complete quest fix.

Use pauses to prove a fix

A breakpoint is a tool for investigation, not a repair. Inspect values, identify the incorrect assumption, change the source, and run the same action again. Remove or disable temporary breakpoints when finished.

In your activity, pair each fix with the required comment and verify it by stepping through the relevant path. A clear diagnosis explains which value was wrong and how the change makes it correct.

Pause at the boundary that makes an off-by-one visible

Use a disposable local script with a three-item list, not your completed assessment solution:

const labels = ['One', 'Two', 'Three'];
for (let index = 0; index <= labels.length; index++) {
  console.log(index, labels[index]);
}

Set a breakpoint on the log line, reload and inspect index and labels.length in Scope. Step over each iteration. You should see indexes 0, 1, 2 and then 3. At 3, the list length is still 3 but labels[3] is undefined: the condition allowed one position beyond the final valid item.

Predict what happens if the condition becomes index < labels.length, then try it in the rehearsal and pause again. Do not submit this toy list as your bug-fix activity. The skill is identifying the incorrect boundary with evidence.

A null-selector error can stop the program before a later loop or undefined-name bug is reached. Fix and rerun the earliest failure, then investigate the next. If a breakpoint never pauses, confirm the file loads in Network, the action reaches that line and the breakpoint is enabled. Source maps can show original files when code is bundled; in your simple app.js rehearsal the source is direct.

Step out finishes the current function and returns to its caller; Resume continues until the next breakpoint or completion. Use these deliberately instead of clicking controls at random. Remove temporary debugger statements when finished, and verify the final behaviour without pauses.