Debugging Introduction

You will use a methodical debugging process in JavaScript, combining debugger;, DevTools, and targeted logging to find the cause of a bug instead of guessing.

What it is

Debugging is the controlled process of finding why code behaves differently from what you expect. In JavaScript, a common mental model is: reproduce the bug, narrow the area, inspect values, form a hypothesis, test it, then fix and verify. Related terms include breakpoint, call stack, watch expression, step over, step into, and console logging.

The debugger; statement is a built-in JavaScript breakpoint. When browser DevTools or the Node.js inspector is open, execution pauses at that line. When no debugger is attached, the statement is ignored.

Why it matters

• It turns vague symptoms like “the total is wrong” into concrete evidence about variable values and control flow.
• It helps you find the first bad state, not just the place where the error appears.
• It reduces random edits by forcing you to test one hypothesis at a time.
• It works for logic bugs that do not throw exceptions, such as wrong calculations or missing data.
• It builds a repeatable workflow for browser, Node.js, and frontend projects.

Syntax or steps

1. Open DevTools or start Node.js with the inspector.
2. Place debugger; near the suspected line, or click a line number to set a breakpoint.
3. Run the code until it pauses.
4. Inspect local variables, the call stack, and the current line.
5. Use Step Over to run one line, Step Into to enter a function, and Continue to resume.
6. Change your hypothesis or move the breakpoint until you find the first incorrect value.

Example

function total(items) {
  let sum = 0;

  for (const item of items) {
    sum += item.price * item.quantity;
    debugger;
  }

  return sum;
}

total([
  { price: 2, quantity: 3 },
  { price: 1, quantity: 0 }
]);

Part-by-part:

• function total(items) receives an array of objects with price and quantity.
• let sum = 0; creates the running total.
• The for...of loop visits each item.
• sum += item.price * item.quantity; adds the line total.
• debugger; pauses after the addition, letting you inspect sum and item.
• With DevTools open, the first pause shows sum as 6. After continuing, the second pause still shows 6 because the second quantity is 0.

Common mistakes

• Leaving debugger; in production code. Remove it before committing, or use conditional breakpoints in DevTools instead.
• Using only console.log() for complex state. Logs can be noisy and may not show object state at the exact moment of failure.
• Fixing the symptom instead of the cause. If a value is wrong, trace backward to the first place it became wrong.
• Not reproducing the bug reliably. Without a repeatable input, you cannot prove the fix worked.

When to use it

Use debugger; when you need to inspect live state, step through logic, or understand a call stack. Use console.log() when you need a quick trace, when debugging code that runs without DevTools, or when you want a permanent log in a controlled environment.

Practice

Guided exercise: Copy the example into a browser console or a local HTML file with a script tag. Open DevTools, run the code, and inspect item and sum at each pause. Expected result: two pauses, with sum equal to 6 at both pauses.

Challenge: Modify the second object to { price: 1, quantity: 2 }. Predict the final total, then use debugger; to verify it. Expected final total: 8.

Quick check

Question: What happens if debugger; runs while DevTools is closed?

Answer: The statement is ignored, and execution continues normally.

Summary

Debugging is a methodical search for the first incorrect state, not a random edit-and-hope process. debugger; gives you a precise pause point, while DevTools lets you inspect variables and control flow. Combine it with targeted logging and a clear hypothesis to fix JavaScript bugs reliably.