Hardly any software problem is as common and at the same time as costly as null references. They are among the most frequent causes of system crashes, undefined states, and security vulnerabilities. Every developer has seen an error message like “NullPointerException”, “Object reference not set to an instance of an object”, or “Segmentation fault” at least once.

Pattern 7: Null References and Empty Values: The “Billion-Dollar Mistake”

Tony Hoare, one of the fathers of modern programming languages, later described the introduction of the null reference in the 1960s as his Billion-Dollar Mistake. In 1965, he developed the ALGOL W programming language, and to make it more flexible, he allowed references that could either point to an object or mean “nothing”. At the time, this seemed practical: it saved the need for more complex type constructs and allowed a simple check to see if a value was “there”.

What Hoare didn’t foresee at the time: this seemingly harmless decision would cause countless errors, security problems, and economic damage in the following decades. In practice, null references lead to two typical patterns:

1. Errors occur late – often only at runtime, sometimes under rare conditions.
2. The cause is often difficult to trace because the null value usually originates far from its actual use.

In everyday life, null errors manifest as sporadic crashes or faulty functions. In enterprise systems, this can mean that individual transactions fail or data becomes inconsistent. In critical systems, null references can have particularly serious consequences:

• Security vulnerabilities: Missing null checks sometimes lead to access to memory areas that attackers can exploit.
• Operational disruptions: Web servers or microservices crash because a field is unexpectedly null.
• Cascading effects: In distributed systems, a single null error can trigger a domino effect, for example, when message queues or API calls are blocked.

Particularly dangerous are silent null errors: when the code tries to access an object that is null, and the language simply ignores this access or returns a default value. This can lead to data corruption that may remain undetected for a long time.

Modern software development has learned from this mistake. Instead of writing null checks everywhere, the following applies today:

1. Non-Null-by-Default: Many modern languages like Kotlin, Swift, or TypeScript set the default to “not null” with strictNullChecks. A value must be explicitly declared as optional if it can be missing.
2. Option or Maybe Types: Instead of using null, functions return, for example, Option<T> or Maybe<T>. The compiler then forces the “no value present” case to be handled explicitly.
3. Enforce Invariants in the Constructor: Objects should never exist in a semi-initialized state. Mandatory fields are set directly upon creation and remain valid throughout their entire lifecycle.
4. Explicit Domain Representation of “Not Present”: Instead of simply using null, the absence of a value should be represented in the domain, for example, as NotApplicable, Unknown, or Empty.
5. Utilize Static Analysis and Linters: Tools like SonarQube, ESLint, or FindBugs detect many null risks even before the build.

However, null references are not just a technical problem but also a mental pattern; they are often the quick way out to solve something provisionally. But every null is a suspended system state that can potentially take revenge months later. Teams that internalize this attitude drastically reduce null errors.

Tony Hoare’s Billion-Dollar Mistake is a reminder that design decisions incur long-term costs. Anyone developing new software today should consistently avoid null values wherever possible. Explicit types, compiler checks, and clear domain models prevent not only sporadic crashes but also expensive and hard-to-diagnose operational errors.

(mack)

Don’t miss any news – follow us on Facebook, LinkedIn or Mastodon.

This article was originally published in German. It was translated with technical assistance and editorially reviewed before publication.