TypeError in JavaScript: a value is not shaped as expected

This is by far the most encountered error in JavaScript, and its message is often read the wrong way. It does not say the code is wrong, it says a value was not the one expected at that spot.

Put differently, the problem nearly always comes from somewhere else: from the line that produced the value, not the line that broke.

Definition

A TypeError is thrown when an operation targets a value whose type does not allow it: reading a property on null, calling something that is not a function, walking through something that cannot be walked through.

const user = null;

try {
  console.log(user.name);
} catch (err) {
  console.log(err.name);      // TypeError
  console.log(err.message);   // Cannot read properties of null (reading 'name')
}

The message names the offending value and the property that was asked for. That is already half the diagnosis: what remains is tracing back to where user took that value.

The messages you read the most

Those four rows cover most of what shows up in production. The first case is by far the most frequent, and almost always tied to data received from the network.

Preventing them rather than catching them

A TypeError reports a defect to fix, not a situation to recover from. Two tools in the language remove the whole class of these errors.

const response = { profile: null };

// Breaks: Cannot read properties of null
// console.log(response.profile.name);

// Safe: optional chaining stops short and hands back undefined
console.log(response.profile?.name);   // undefined

// Safe, with a fallback value
console.log(response.profile?.name ?? "Anonymous");   // Anonymous

Optional chaining (?.) cuts short as soon as a step is null or undefined, and Nullish coalescing (??) supplies the fallback. Checking the shape of the data on the way in remains the sturdiest protection of all.

Frequently asked questions

A ReferenceError is about a name that exists nowhere, a TypeError about a value that exists but does not fit. A variable never declared gives you the first, a declared variable holding undefined gives you the second the moment you read a property off it.

Rarely. A try placed around a TypeError hides a defect instead of fixing it, and the program carries on with inconsistent data. Reserve recovery for expected failures, network or user input, and fix the rest at the source.

By reading the error's call stack, which gives the run of functions it passed through. The reported line is the one that broke, but the cause often sits one or two entries below, where the value was built in the first place.