Tony Hoare called null "the billion-dollar mistake." The bug shows up in every nullable-by-default language: a function returns null or undefined under some condition, the caller doesn't check, and the next access throws a runtime error or — worse — returns a confusing default.

The cure is a type system that distinguishes T from T | null and forces a check. TypeScript's strictNullChecks, Kotlin's nullable types, Rust's Option<T>, Swift's optionals — all of them turn the bug into a compile error. Languages without that discipline still have the bug, but disciplined teams use defensive patterns: return-empty-collection-instead-of-null, the Null Object pattern, or runtime invariants checked at function entry.

Even with strict null types, there's an escape hatch — as, !, unwrap(), ?. chains that swallow nulls — and code review catches the abuses where the type system can't.

Review heuristic

Search the diff for ! non-null assertions, unwrap() calls, and as Type casts. Each is an assertion the author is making to the compiler. Each needs to be either justified in a comment or replaced with a real null check.

External reference

CWE-476: NULL Pointer Dereference — the canonical industry classification for this bug class. Useful when filing tickets, writing security policies, or arguing with a static analyzer.