Advanced debugging

Advanced debugging means asking narrower questions

You already know the basics from Debugging in the browser: set a breakpoint, step, read Scope, and add Watch expressions. You also learned in Reading error messages that the top stack frame is evidence, not a verdict. This lesson builds on those skills instead of repeating them.

The tools are sharper than a plain line breakpoint: conditional breakpoints, hit counts, logpoints, DOM breakpoints, event listener breakpoints, XHR/fetch breakpoints, exception pause, Ignore List, async stack traces, and the Node inspector. The professional move is choosing the smallest tool that answers the current question.

You will connect this lesson to try/catch, custom errors, async/await, promise errors, bundlers and source maps, and JavaScript runtimes.

Advanced tools are useful only after the bug is repeatable. Use a simple loop: reproduce the failure, isolate the smallest path, hypothesize one cause, verify with an observation, then fix the smallest line and rerun from the start.

Binary search is the same method with math. If a list of changes contains one bad change, test the middle. If the middle fails, search the first half; if it passes, search the second half. Rubber-ducking helps because saying each value aloud often reveals the assumption you never tested.

1const changes = [2  { id: "a-route", label: "add account route" },3  { id: "b-layout", label: "move checkout layout" },4  { id: "c-copy", label: "rewrite button copy" },5  { id: "discount-formula", label: "replace discount formula" },6  { id: "e-theme", label: "adjust theme tokens" },7  { id: "receipt-cache", label: "cache receipt payload" },8];9 10function testUpTo(index) {11  return changes.slice(0, index + 1).some(change => change.id === "discount-formula")12    ? "fail"13    : "pass";14}15 16function bisectFirstBad() {17  let low = 0;18  let high = changes.length - 1;19  const steps = [];20  while (low < high) {21    const mid = Math.floor((low + high) / 2);22    const result = testUpTo(mid);23    steps.push(`test through ${changes[mid].id}: ${result}`);24    if (result === "fail") high = mid;25    else low = mid + 1;26  }27  return { first: changes[low], steps };28}29 30const report = bisectFirstBad();31console.log(report.first.label);32console.log(report.steps.join(" | "));

In Chrome DevTools, open the Sources panel, right-click a line number, and choose Add conditional breakpoint... or Add logpoint.... The official UI also includes DOM breakpoints from the Elements panel’s Break on menu, Event Listener Breakpoints, XHR/fetch Breakpoints, and the Pause on exceptions control. Firefox DevTools uses the same names for conditional breakpoints, logpoints, Event Listener Breakpoints, XHR breakpoints, and source maps; it still commonly calls skipped library files blackboxed sources.

1// Chrome DevTools Sources panel names to look for:2// Add conditional breakpoint...    item.id === 423// Add logpoint...                  "item", item.id, item.stock4// DOM breakpoints                  subtree modifications, attribute modifications, node removal5// Event Listener Breakpoints       click, input, timer, animation, and more6// XHR/fetch Breakpoints            pause when the request URL contains text7// Pause on exceptions              uncaught only, or caught and uncaught8// Ignore List                      skip framework or extension scripts while stepping

Conditional breakpoints evaluate an expression in the paused line’s scope, such as item.id === 42. Hit counts answer repeated-action bugs: pause on the third click, the tenth timer tick, or the second call from a test. Logpoints print without editing source and without pausing, which is safer when pausing changes timing.

1const items = [Run2  { id: 17, label: "keyboard", stock: 4 },3  { id: 42, label: "monitor", stock: -1 },4  { id: 58, label: "dock", stock: 3 },5];6 7function firstBrokenItem(items, breakWhen) {8  const log = [];9  for (const item of items) {10    log.push(`checking ${item.id}`);11    if (breakWhen(item)) {12      return { item, log };13    }14  }15  return { item: null, log };16}17 18const result = firstBrokenItem(items, item => item.id === 42);19console.log(result.item.id);20console.log(result.log.join(" -> "));

1const items = [2  { id: 17, label: "keyboard", stock: 4 },3  { id: 42, label: "monitor", stock: -1 },4  { id: 58, label: "dock", stock: 3 },5];6 7function firstBrokenItem(items, breakWhen) {8  const log = [];9  for (const item of items) {10    log.push(`checking ${item.id}`);11    if (breakWhen(item)) {12      return { item, log };13    }14  }15  return { item: null, log };16}17 18const result = firstBrokenItem(items, item => item.id === 42);19console.log(result.item.id);20console.log(result.log.join(" -> "));

A logpoint is often the bridge between console.log and a breakpoint. It gives a clue while the program keeps running. The local tracer below is not DevTools, but it demonstrates the same idea: print only when a condition is true, and keep the source behavior otherwise unchanged.

1function withConditionalTrace(fn, shouldLog) {2  return (...args) => {3    const result = fn(...args);4    if (shouldLog(args, result)) {5      console.log(`${fn.name}(${args.join(", ")}) -> ${result}`);6    }7    return result;8  };9}10 11const priceWithTax = (price, rate) => Number((price * (1 + rate)).toFixed(2));12const tracedPrice = withConditionalTrace(priceWithTax, (args, result) => result > 50);13console.log(tracedPrice(20, 0.1));14console.log(tracedPrice(60, 0.1));

A synchronous stack is the current call stack. Older JavaScript engines often stopped at the event loop boundary: after a promise, timer, or callback resumed, the original caller was gone. Modern V8 reconstructs many await chains with “zero-cost async stack traces,” so Node and Chrome can show frames such as at async outer below the throwing function.

1Error.stackTraceLimit = 20;2 3async function leaf() {4  await Promise.resolve();5  throw new Error("boom from leaf");6}7 8async function middle() {9  await leaf();10}11 12async function outer() {13  await middle();14}15 16outer().catch(error => {17  console.log(error.stack.split("\n").slice(0, 5).join("\n"));18});

Stack strings are useful but not standardized. V8 writes frames like at async outer (file.js:12:3). Firefox uses a different shape, often outer@file.js:12:3. Treat stacks as human-readable evidence, not a portable data format.

1function createInputError(message) {2  const error = new Error(message);3  Error.captureStackTrace?.(error, createInputError);4  return error;5}6 7function validateCart() {8  return createInputError("missing total");9}10 11console.log(validateCart().stack);

Error.captureStackTrace is V8-specific. It lets a library create an error and omit helper frames above a constructor or factory function. For cross-runtime code, guard it with optional chaining and keep the error useful without it.

1const networkError = new Error("request failed");2const checkoutError = new Error("checkout failed", { cause: networkError });3 4console.log(checkoutError.message);5console.log(checkoutError.cause.message);

error.cause connects a high-level error to the lower-level failure without flattening both messages into one string. console.trace() prints the current stack without throwing. Error.stackTraceLimit changes how many V8 frames are collected. These are diagnostic tools, not business logic.

1function leaf() {2  console.trace("discount path");3}4 5function outer() {6  leaf();7}8 9outer();

A source map connects generated code back to authored code. Bundlers and transpilers may minify, concatenate, or turn TypeScript into JavaScript. The browser runs the generated file, but DevTools can display and breakpoint the original source when it can find the map.

1export function originalName(total: number) {2  throw new Error("mapped failure for " + total);3}4 5originalName(42);

1export function originalName(total) {2  throw new Error("mapped failure for " + total);3}4originalName(42);5//# sourceMappingURL=checkout.js.map

The comment //# sourceMappingURL=checkout.js.map is the breadcrumb DevTools or Node follows. In Chrome, source maps can be enabled or disabled in Settings Preferences Sources with Enable JavaScript source maps, or through the Command Menu by searching for source maps. If a framework or map marks vendor files as ignored, Chrome’s Ignore List skips them while stepping; many developers still say “blackboxing.”

1# Browser builds usually attach a comment near the end of the file:2# //# sourceMappingURL=checkout.js.map3 4# Node can remap stack traces when the .js file and .map file are present:5node --enable-source-maps dist/checkout.js6 7# Many production web builds keep maps private instead:8# use a hidden-source-map setting, upload the .map files to your error tracker,9# and do not publish sourceMappingURL comments for users to download.

Node can be debugged with the same inspector protocol Chrome DevTools uses. Start a process with --inspect, open chrome://inspect, and attach. Use --inspect-brk when the bug happens during startup and you need to pause before the first line of user code.

1# Start Node with the inspector and attach Chrome DevTools from chrome://inspect.2node --inspect server.js3node --inspect-brk server.js4 5# Debug the built-in test runner before the first line runs.6node --test --inspect-brk tests/checkout.test.mjs7 8# Use the terminal debugger when you only have a shell.9node inspect server.js

VS Code’s JavaScript Debug Terminal automatically launches Node programs with debugging enabled. A launch.json can pin the program, arguments, environment, and source-map behavior for a team. When you only have a terminal, node inspect provides a CLI debugger. For tests, node --test --inspect-brk pauses the built-in test runner before the test file executes.

1NODE_DEBUG=http,net node server.js2 3node -e "const util = require('node:util'); console.log(util.inspect(obj, { depth: 4 }))"4 5process.on('uncaughtException', (error) => {6  console.error(error);7  process.exitCode = 1;8});9 10process.on('unhandledRejection', (reason) => {11  console.error(reason);12  process.exitCode = 1;13});

NODE_DEBUG=http,net prints built-in subsystem diagnostics. util.inspect(value, { depth: 4 }) controls how deeply objects are printed. Process handlers for uncaughtException and unhandledRejection are last-resort reporting hooks: log, set a failing exit code, and fix the original error path rather than pretending the process is healthy.

Three production-shaped bugs show how the tools combine. A bug that only happens on the third click wants a hit count, event listener breakpoint, or condition. A wrong value inside a loop wants item.id === 42 or a logpoint. A swallowed promise rejection wants exception pause, async stacks, and an error cause chain.

1let clickCount = 0;Run2let submitted = false;3 4function handleCheckoutClick() {5  clickCount += 1;6  if (clickCount === 3) {7    submitted = true;8    return "submitted twice";9  }10  return "waiting";11}12 13console.log(handleCheckoutClick());14console.log(handleCheckoutClick());15console.log(handleCheckoutClick());

1async function saveOrder() {2  throw new Error("network down");3}4 5async function checkout() {6  try {7    await saveOrder();8    return "saved";9  } catch (error) {10    return "saved"; // bug: the rejection was swallowed11  }12}13 14checkout().then(status => console.log(status));

The bad code returns "saved" even when saveOrder throws. Pause on caught exceptions to stop at the throw site, then fix the path so callers see a meaningful failure and the original cause stays attached.

1async function saveOrder() {2  throw new Error("network down");3}4 5async function checkout() {6  try {7    await saveOrder();8    return { ok: true };9  } catch (error) {10    throw new Error("checkout failed", { cause: error });11  }12}13 14checkout().catch(error => console.log(error.cause.message));

1function submitForm(form) {2  // Temporary local-only pause. Remove it before sharing code.3  debugger;4  return form.checkValidity();5}

A debugger; statement is a real JavaScript pause for local work. It is useful when generated files make line breakpoints hard to place. Do not leave it in shared code; prefer DevTools breakpoints or tests once the bug is understood.

Common misconceptions

These questions mix tool choice with real output. Answer from evidence, not from the tool name alone.

Key takeaways

• Start with reproduce, isolate, hypothesize, verify; tools support the method.
• Conditional breakpoints, hit counts, logpoints, DOM breakpoints, event listener breakpoints, XHR/fetch breakpoints, and exception pause answer different questions.
• Async stack traces reconnect many await chains, but stack strings are engine-specific evidence.
• Source maps map generated code to authored code; keep production maps private when they expose source.
• Node debugging includes the inspector, VS Code, node inspect, test debugging, NODE_DEBUG, and careful process-level error handling.

Up next: Creational patterns.