The console and reading error messages

When a program goes wrong, two things tell you what happened: what it printed, and the errors it threw. The console is how a program prints for its developer. console.log is the method everyone knows, but table, group, count, assert and error each make a particular job easier. An error is an object with a name that says what kind of problem it is (TypeError, ReferenceError …), a message that says what went wrong, and a stack trace that says where: the chain of function calls that led to the failing line. This lesson prints with the console methods that earn their place, reads a stack trace from the top, and shows something that catches out many tests: two engines word the same error differently, so code should check an error’s type, never its message.

The console methods worth knowing

console is not part of ECMAScript. It is a host API, specified by the WHATWG Console Standard and provided by browsers, Node.js and the Run buttons of this track. The methods you will use most:

Here are most of them at work on the results of one test run:

// The console methods worth knowing, on the results of one CI run.
const jobs = [
  { job: 'lint', seconds: 12, passed: true },
  { job: 'unit tests', seconds: 48, passed: true },
  { job: 'e2e tests', seconds: 230, passed: false },
];

console.log('jobs:', jobs.length, 'first:', jobs[0]);
console.table(jobs);

console.group('failed jobs');
for (const j of jobs.filter((x) => !x.passed)) console.log(`${j.job} after ${j.seconds} s`);
console.groupEnd();

for (const j of jobs) console.count(j.passed ? 'passed' : 'failed');

console.assert(jobs.every((j) => j.passed), 'not every job passed');
console.log('the program goes on after a failed assert');
console.error('error: e2e tests failed');

jobs: 3 first: { job: 'lint', seconds: 12, passed: true }
┌─────────┬──────────────┬─────────┬────────┐
│ (index) │ job          │ seconds │ passed │
├─────────┼──────────────┼─────────┼────────┤
│ 0       │ 'lint'       │ 12      │ true   │
│ 1       │ 'unit tests' │ 48      │ true   │
│ 2       │ 'e2e tests'  │ 230     │ false  │
└─────────┴──────────────┴─────────┴────────┘
failed jobs
  e2e tests after 230 s
passed: 1
passed: 2
failed: 1
the program goes on after a failed assert

Assertion failed: not every job passed
error: e2e tests failed

jobs: 3 first: { job: 'lint', seconds: 12, passed: true }
┌─────────┬──────────────┬─────────┬────────┐
│ (index) │     job      │ seconds │ passed │
├─────────┼──────────────┼─────────┼────────┤
│    0    │    'lint'    │   12    │  true  │
│    1    │ 'unit tests' │   48    │  true  │
│    2    │ 'e2e tests'  │   230   │ false  │
└─────────┴──────────────┴─────────┴────────┘
failed jobs
  e2e tests after 230 s
passed: 1
passed: 2
failed: 1
the program goes on after a failed assert

Assertion failed: not every job passed
error: e2e tests failed

Two lines in that output deserve a second look. console.assert printed Assertion failed: not every job passed and the program carried on: the Console Standard defines assert as a logger, not a check that throws, and Node.js documents that it “does not otherwise affect execution”. And the assert and console.error lines appear on standard error, which a terminal shows mixed with the other output but a script can capture apart.

The console also behaves differently in a browser and in Node.js. Node.js turns every value into text at the moment of the call. A browser’s developer tools show an object you can expand, and MDN warns that its content is read lazily, when you first look at it: log an object, change it, then expand the log entry, and you see the changed object. When you need a snapshot, log a copy, such as structuredClone(obj), or the parts you care about.

The browser’s alert(), confirm() and prompt() show a dialog and stall the page until it is closed, by the HTML Standard’s own description, so they make poor debugging tools. This track prints with the console and changes the page with the DOM.

Reading an error message and its stack trace

This program prints a label for each order. The second order has no customer, so reading the customer’s name throws, three function calls deep, and nothing catches the error:

// An order without its customer: reading the customer's name throws, three calls deep.
function customerName(order) {
  return order.customer.name;
}

function label(order) {
  return `${order.id}: ${customerName(order)}`;
}

function printLabels(orders) {
  for (const order of orders) console.log(label(order));
}

printLabels([{ id: 'A-1', customer: { name: 'Asha' } }, { id: 'A-2' }]);

A-1: Asha

stack-trace.mjs:3
  return order.customer.name;
                        ^

TypeError: Cannot read properties of undefined (reading 'name')
    at customerName (stack-trace.mjs:3:25)
    at label (stack-trace.mjs:7:26)
    at printLabels (stack-trace.mjs:11:43)
    at stack-trace.mjs:14:1
    at ModuleJob.run (node:internal/modules/esm/module_job:561:25)
    at async node:internal/modules/esm/loader:647:26
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:101:5)

Node.js v24.21.0

Node.js printed the first label, then stopped with the error. Read it from the top:

1. The source line and a caret. stack-trace.mjs:3 names the file and line, and the ^ marks the expression that failed: .name, read from order.customer, which is undefined.
2. The name and message. TypeError says the operation was not possible on that kind of value; Cannot read properties of undefined (reading 'name') says which operation.
3. The stack, innermost call first. Each at line is one function call, with its file, line and column: customerName failed on line 3, called by label on line 7, called by printLabels on line 11, called from the top level of the file on line 14. The last frames, node:internal/…, are Node.js’s own code that loaded the module; you can stop reading when they start.

The first frame in your own code is usually where the fix belongs, but not always. Here the bug may be the order without a customer, which came from elsewhere; the stack shows the path the bad value travelled, so you can choose where to handle it.

A-1: Asha

TypeError: cannot read property 'name' of undefined
    at customerName (stack-trace.mjs:3:24)
    at label (stack-trace.mjs:7:38)
    at printLabels (stack-trace.mjs:11:48)
    at <anonymous> (stack-trace.mjs:14:12)

The name of an error is its class, and ECMA-262 defines the classes an engine throws:

EvalError also exists, but the specification no longer throws it and keeps it only for compatibility.

The same mistake in two engines

A message is meant for people, and each engine writes its own. This program makes seven common mistakes and prints the name and message of each error:

// Seven common mistakes. Each one throws; the program prints the error's name and message.
const mistakes = {
  'read a property of null': () => {
    const order = null;
    return order.total;
  },
  'read a property of undefined': () => {
    const order = {};
    return order.customer.name;
  },
  'call something that is not a function': () => {
    const order = { total: 5 };
    return order.total();
  },
  'use a name that was never declared': () => totl + 1,
  'use a let variable before its line': () => {
    const copy = later;
    let later = 1;
    return copy;
  },
  'assign to a constant': () => {
    const n = 1;
    n = 2;
    return n;
  },
  'make an array of length -1': () => new Array(-1),
};

for (const [mistake, run] of Object.entries(mistakes)) {
  try {
    run();
  } catch (error) {
    console.log(`${mistake}\n  ${error.name}: ${error.message}`);
  }
}

read a property of null
  TypeError: Cannot read properties of null (reading 'total')
read a property of undefined
  TypeError: Cannot read properties of undefined (reading 'name')
call something that is not a function
  TypeError: order.total is not a function
use a name that was never declared
  ReferenceError: totl is not defined
use a let variable before its line
  ReferenceError: Cannot access 'later' before initialization
assign to a constant
  TypeError: Assignment to constant variable.
make an array of length -1
  RangeError: Invalid array length

read a property of null
  TypeError: cannot read property 'total' of null
read a property of undefined
  TypeError: cannot read property 'name' of undefined
call something that is not a function
  TypeError: not a function
use a name that was never declared
  ReferenceError: 'totl' is not defined
use a let variable before its line
  ReferenceError: later is not initialized
assign to a constant
  TypeError: 'n' is read-only
make an array of length -1
  RangeError: invalid array length

Every mistake produced the same error name in both engines, and every message differs, if only by a quote mark or a capital letter. Browsers differ in the same way. MDN’s error reference lists the wording of each family of engines; three of the mistakes above read like this:

So the message is for reading, and the name is for code. A test that compares error.message with V8’s wording passes on Node.js and fails in Safari, in Firefox and in the Run button, although the code behaves the same in all of them.

Catching an error and checking what it is

try … catch hands you the error object, and its standard properties are name and message, plus cause when the code that threw it gave one. The stack property is not part of ECMA-262 at all: engines add it, each in its own format, as the next run shows.

// A function that throws on bad input, and a caller that looks at what it caught.
function parsePrice(text) {
  const value = Number(text);
  if (!Number.isFinite(value)) throw new RangeError(`not a price: ${JSON.stringify(text)}`);
  return value;
}

try {
  parsePrice('12,50');
} catch (error) {
  console.log('instanceof RangeError:', error instanceof RangeError);
  console.log('name:', error.name);
  console.log('message:', error.message);
  console.log('stack:');
  console.log(error.stack);
}

instanceof RangeError: true
name: RangeError
message: not a price: "12,50"
stack:
RangeError: not a price: "12,50"
    at parsePrice (catch-and-inspect.mjs:4:38)
    at catch-and-inspect.mjs:9:3
    at ModuleJob.run (node:internal/modules/esm/module_job:561:25)
    at async node:internal/modules/esm/loader:647:26
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:101:5)

instanceof RangeError: true
name: RangeError
message: not a price: "12,50"
stack:
    at parsePrice (catch-and-inspect.mjs:4:52)
    at <anonymous> (catch-and-inspect.mjs:9:13)

The message here came from our own code, so it is the same everywhere; only engine-made messages vary. To decide what to do with an error, check its class with instanceof (error instanceof RangeError) or its name. Your own errors can carry a code property or a class of their own, which a later lesson builds. And Error.isError(value), new in ECMAScript 2026, tells you whether a value is a real error object at all, even one from another realm such as an iframe, where instanceof gives a wrong false; Node.js 24 already has it.

Exercise: fix the TypeError

Old orders sometimes arrive without a customer or without an address, and shippingLabel throws on them. Read the error the sample tests report, find the expression that fails, and make the function print placeholders instead.

TypeError: Cannot read properties of undefined (reading 'name')

/**
 * The line printed on a parcel: order id, customer name and city, separated by " · ".
 * @param {{ id: string, customer?: { name?: string, address?: { city?: string } } }} order
 * @returns {string}
 */
export function shippingLabel(order) {
  return `${order.id} · ${order.customer.name} · ${order.customer.address.city}`;
}

import { test, assert } from 'mysmartcopilot:test';
import { shippingLabel } from './label.mjs';

test('a complete order prints id, name and city', () => {
  assert.equal(shippingLabel({ id: 'A-1', customer: { name: 'Asha', address: { city: 'Pune' } } }), 'A-1 · Asha · Pune');
});

test('an order without a customer does not throw', () => {
  assert.equal(shippingLabel({ id: 'A-2' }), 'A-2 · unknown customer · no city');
});

test('a customer without an address keeps the name', () => {
  assert.equal(shippingLabel({ id: 'A-3', customer: { name: 'Ravi' } }), 'A-3 · Ravi · no city');
});

test('an empty city is a value the customer gave, so it stays', () => {
  assert.equal(shippingLabel({ id: 'A-4', customer: { name: 'Meera', address: { city: '' } } }), 'A-4 · Meera · ');
});

Interview questions

Fresher · What do the name, the message and the stack of a JavaScript error tell you?

The name is the error’s class, such as TypeError, ReferenceError or RangeError, and says what kind of problem it is; ECMA-262 defines these classes, so the name is the same in every engine. The message says what exactly went wrong, in words chosen by whoever threw it: your own code, or the engine, whose wording differs between V8, SpiderMonkey, JavaScriptCore and QuickJS. The stack, which engines add although ECMA-262 does not define it, lists the chain of calls that led to the error, innermost first, with file, line and column; the first frame in your own code is where to start looking. In practice: read the message to understand, read the stack to locate, and in code or tests branch on the name or the class, with instanceof, never on the message text.

Key takeaways

• console comes from the host, specified by the WHATWG Console Standard. table, group, count and assert save time; error and warn go to standard error in Node.js; assert never stops the program.
• Browsers read logged objects lazily, when you expand them; Node.js prints text at the moment of the call.
• Read an error from the top: the line and caret, then the name and message, then the stack, innermost call first, until Node.js’s own frames start.
• Error names come from ECMA-262 and match in every engine; messages and the stack format do not. Check the class or the name, never the message text.