Platform under construction

Errors & Debugging

Advanced

Breakpoints & debugger

Breakpoints pause running code so you can inspect variables, call stack and execution flow at the exact line that matters.

function calculateTotal(items) {
  debugger;
  return items.reduce((sum, item) => sum + item.price, 0);
}

Errors & Debugging

Breakpoints let you debug the real runtime state.

A breakpoint pauses code in the browser developer tools. While paused, you can inspect variables, step through lines and see the call stack.

The debugger statement is a breakpoint written in code. It pauses only when developer tools are open.

Use breakpoints when logs are not enough. They are especially useful for conditions, loops, event handlers and code that changes state over time.

Breakpoint

A pause point set in developer tools.

debugger

A statement that pauses execution when devtools are open.

Step over

Run the current line and pause at the next one.

Call stack

Shows how execution reached the paused line.

Examples

Good debugging code keeps the failure path visible.

Breakpoint used to inspect a specific condition

for (const record of records) {
  if (record.status === "ready") {
    debugger;
  }
}

Leaving debugger in shipped code

function render() {
  debugger;
  updatePage();
}

// This should not be committed accidentally.

Code patterns

Reusable examples for quick reference.

These examples focus on the debugging patterns you will reuse: safe parsing, throwing, custom error types, console inspection, breakpoints and async failure handling.

debugger statement

Pause at the exact line during development.

function render(records) {
  debugger;
  return records.length;
}

Conditional breakpoint

Pause only when a condition is true.

// In DevTools, set a breakpoint condition:
// record.status === "ready"

Inspect loop state

Breakpoints are useful inside loops.

for (const record of records) {
  if (!record.title) {
    debugger;
  }
}

Remove before commit

debugger should not stay in production code.

// Search before commit:
// rg "debugger"

Rules that matter

Make failures observable and recoverable where possible.

Debugging starts before something breaks. Clear error types, helpful messages and visible failure states make the code easier to repair.

Use breakpoints for state

Pause when you need real values, not guesses.

Inspect the call stack

It explains how execution reached this line.

Use conditional breakpoints

They reduce noise in loops and repeated events.

Step carefully

Step over, into and out answer different questions.

Remove debugger statements

They are development tools, not production code.

Combine with logs when useful

Logs show history; breakpoints show current state.

Production thinking

Reliable software is built by handling failure deliberately.

Why does this matter?

Breakpoints turn debugging from print-and-guess into direct inspection.

Accessibility

Breakpoints help inspect focus, keyboard and ARIA state changes at the moment they happen.

Production note

Production builds should block committed debugger statements through linting or review.

SEO note

Breakpoints help find render paths that fail before content reaches the page.

Live code lab

Change the HTML, CSS or JavaScript and run the result.

The preview runs inside an isolated iframe. The JavaScript is placed inside the HTML editor for now, so every example stays together and remains easy to understand.

Mini assignment

Try this now.

Add a debugger statement inside the reduce callback, then remove it again.
Add another record and inspect the steps.
Write the condition you would use for a conditional breakpoint.

Practice assignment

Do this before moving to the next topic.

Set one breakpoint in DevTools.
Inspect one variable while paused.
Explain the call stack.

HTML + JavaScript CSS

Live preview

Self-check

Before you continue, prove that you understand Breakpoints & debugger.