beginner25 minby DevFox

Null, undefined, and Strict Null Checks

Two different kinds of nothing, the errors they cause at runtime, and how strict null checking turns that whole category of crash into a compile error.

TypeScript

The most common error in this family of languages reads:

text

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

Something was expected to be there and was not. A lookup found no match, an optional field was never filled in, a list came back empty. The program carried on as though it had a value, asked that value a question, and stopped.

This lesson is about the two ways a value can be absent, and about one compiler setting that converts that entire category of runtime crash into a message you see while typing. It is the single strongest argument for using this language.

Two kinds of nothing

typescript

let selected: string | null = null;      // deliberately empty
let notSetYet;                           // undefined

null means "there is no value here, and that is intentional". You write it yourself: a customer with no middle name, a search that found nothing.

undefined means "no value has been provided". You rarely write it — the language produces it:

typescript

let name;                       // declared, never assigned
customer.middleName;            // a property that is not there
list[99];                       // a position past the end
function noReturn() {}
noReturn();                     // a function that returns nothing

null

A decision somebody made.

You write it yourself: a customer with no middle name, a search that found nothing and says so.

undefined

A question nobody answered.

The language produces it whether you want it or not — an unassigned name, a missing property, a position past the end, a function that returns nothing.

Both are falsy, and both crash if you ask them for a property

The setting that changes everything

In tsconfig.json:

strict turns on several checks; the one that matters most here is strictNullChecks. Without it, null and undefined are allowed anywhere:

With it on, absence is part of the type and has to be declared:

string | null is a union: a value that is one of several types. Now the checker knows this can be absent, and refuses to let you ignore it:

That error is the crash from the top of this lesson, reported before anything ran. Turn strict on in every project, from the first day. Adding it to an existing codebase produces hundreds of errors, and each one is a place that could crash.

Narrowing

The checker will not let you use a possibly-absent value. It will let you use it once you have proven it is there:

Inside the if, name is null. After it, TypeScript knows the only remaining possibility is string, so the method call is allowed. That is narrowing, and it is the central mechanism of the type system — the unions lesson develops it properly.

You do not have to check for each separately:

This is the one place the converting == earns its keep, and it is worth a comment if your team is strict about ===.

The early return is usually the clearest shape:

Handle the absent case, leave, and let the rest of the function work with a value it knows exists.

The escape hatch, and why not to use it

Bad — telling the checker to stop worrying.

Good — handling the case, or saying it cannot happen and why.

The ! is the non-null assertion: it tells the checker "I know this is not null". It performs no check and generates no code — it is you overruling the only thing protecting you.

So the first version compiles cleanly and crashes at runtime for any customer without an address, with exactly the error this lesson opened with. Worse, it looks more confident than the unchecked version would have, so a reviewer reads it as deliberate.

There is a narrow legitimate use — you know something the checker cannot, such as a value populated by a framework before your code runs. Even then, prefer a check that also documents the assumption:

That throws a message naming the problem instead of a TypeError naming a property.

Optional properties and parameters

? makes a property optional, which means its type is string | undefined. Reading it gives undefined when absent, and the checker requires you to handle that.

The same for parameters:

Optional parameters must come after required ones.

There is a real difference between an optional property and one explicitly typed as possibly-undefined:

B requires you to write the key, even if the value is undefined. That matters when something distinguishes "not provided" from "provided as empty" — an update that should leave a field alone versus one that should clear it.

Where absence actually comes from

Four places produce most of it, and knowing them tells you where to put the checks.

Lookups that find nothing
customers.find(...) is Customer | undefined, always. The checker tells you, every time.
Reading past the end of a list
By default the checker believes list[0] is a value, which is a known unsoundness. noUncheckedIndexedAccess makes it T | undefined and is worth turning on.
Data from a form, a file, or an API
The checker believes whatever you declared and nothing verified it. A later lesson is entirely about validating at this boundary.
Functions with no return value
They give undefined, which is easy to forget when you assign the result of one to a name.

Only the third one is invisible to the checker, which is what makes it the dangerous one

Put your handling where the absence enters. A value checked once at the edge is a value the rest of your code can use freely, which is far better than every function defending itself.

A cheat sheet to keep

Where to go next

You have met the mechanism that removes the most common runtime crash in this family of languages, and the one operator that switches it back off. strict: true and never writing ! are two decisions worth making now and not revisiting.

Next is Arrays and Tuples, the first collections — many values under one name, the operations for working through them, and the position where absence appears again in a way the checker does not warn about by default.

Before you move on, open your tsconfig.json and confirm "strict": true is set. Then write a function taking string | null, use the parameter without checking, and read the error. Then add the check and watch the error disappear as you type the if. That is the type system doing the thing it exists for.