Kotlin's Billion-Dollar Fix: Null Lives in the Type System

Tony Hoare called the null reference his “billion-dollar mistake” — a single design choice that produced decades of crashes. Java inherited it whole: any reference can be null, and the compiler never makes you check. Kotlin’s fix isn’t a runtime guard or a linter pass; it moves nullability into the type system, so “could this be null?” has an answer the compiler enforces before your code runs.

We met the idea in the types chapter and saw the machinery behind it in smart casts. This chapter is the full toolkit — the operators, the escape hatches, the boundary cases, and the one place the guarantee leaks. Everything was run against Kotlin 2.4.10.

Two types, not one

String and String? are different types. The first can never hold null; the second might. That single distinction is the whole foundation:

val name: String = "Ada"      // never null
val maybe: String? = null     // the ? opts into null

Once a value’s type ends in ?, the compiler refuses to let you use it as if it were always present. You have to handle the null case — and the rest of this chapter is the vocabulary for doing that without ceremony. One immediate relief for a Java engineer: == never throws on null. maybe == null and a == b where either might be null are always safe, because Kotlin’s == is a null-aware call to equals, not a raw dereference.

The safe call: ?.

?. calls a member only if the receiver is non-null; otherwise the whole expression short-circuits to null:

val length: Int? = maybe?.length     // null if maybe is null

Safe calls chain, and the chain stops the instant anything in it is null — no nested null checks:

val city: String? = user?.address?.city

The result type of a safe call is always nullable, because “the receiver was null” has to be representable in the answer. That’s what makes the next operator the natural partner.

The Elvis operator: ?:

?: supplies a fallback for when the left side is null (the name is a joke about Elvis Presley’s hair, if you tilt your head):

val length: Int = maybe?.length ?: 0
val city: String = user?.address?.city ?: "unknown"

Because the right-hand side can be any expression, including one that doesn’t produce a value, Elvis pairs naturally with early exits — this is one of the most characteristic shapes in Kotlin:

val token = request.token ?: return null
// past this line, token is a non-null String

That works because return and throw have type Nothing (from the types chapter), the subtype of everything, so they slot into the Elvis without disturbing the result type. The compiler then smart-casts token to non-null for the rest of the function.

The escape hatch: !!

!! asserts “I know this isn’t null” and throws a NullPointerException if you’re wrong, converting T? to T by force:

val length: Int = maybe!!.length     // throws if maybe is null

Treat every !! as a small confession that you know something the compiler doesn’t. Occasionally that’s genuinely true. Far more often it’s a safe call or an Elvis waiting to be written instead — and a !! in a chain (a!!.b!!.c) is a code smell that should send you looking for the honest null handling.

Safe casts: as?

A plain cast (as) throws on a type mismatch. The safe cast as? returns null instead, which composes beautifully with Elvis into a one-line “cast or default”:

val count = value as? Int ?: 0       // 0 if value isn't an Int

Nullable-receiver extensions

Kotlin’s standard library defines functions on nullable types, so you can call them on a value that might be null without a safe call. These read cleanly and are worth knowing, because they replace a lot of manual checking:

val maybe: String? = null
maybe.isNullOrBlank()     // true — no NPE, the receiver may be null
maybe.isNullOrEmpty()     // true
maybe.orEmpty()           // "" — the null becomes the empty string

isNullOrBlank, isNullOrEmpty, and orEmpty (which exists for strings and collections) are the everyday ones. The trick under the hood is that the extension function’s receiver type is String?, so the null check lives inside the function — a pattern you can use in your own extensions.

Doing something only when non-null: ?.let

To run a block only when a value is present, combine the safe call with let. Inside the block the value is non-null:

user.email?.let { address ->
    sendWelcome(address)             // runs only if email != null
}

This is the idiomatic replacement for if (x != null) { ... } when x is a property rather than a local — exactly the case smart casts can’t handle, because a property isn’t stable. ?.let sidesteps the stability question entirely: the safe call captures the value, and let binds that captured value inside the block. (let is one of the scope functions, which get their own chapter.)

Nulls in collections

Keep two shapes distinct: a List<String?> is a non-null list that may contain null elements; a List<String>? is a whole list that might itself be null. The standard library has clean tools for the element case:

val names: List<String?> = listOf("Ada", null, "Linus")
val clean: List<String> = names.filterNotNull()          // ["Ada", "Linus"]

val raw = listOf("1", "x", "3")
val nums: List<Int> = raw.mapNotNull { it.toIntOrNull() } // [1, 3] — map and drop nulls in one pass

filterNotNull drops the nulls and, crucially, changes the element type from String? to String, so the result is a clean non-null list. mapNotNull fuses a transform with the filtering — anything the lambda returns null for is dropped — which is the tool for parsing a list where some entries won’t convert.

lateinit: non-null, but not yet

Sometimes a property genuinely can’t be set in the constructor — dependency injection, a test’s @BeforeEach, a framework lifecycle. Making it nullable just to satisfy initialization would be a lie you then pay for at every use. lateinit var promises the compiler you’ll assign it before first read:

lateinit var repository: UserRepository

fun setUp() {
    repository = UserRepository()
}

Read it before it’s assigned and you get a clear UninitializedPropertyAccessException, not a vague NPE. When you’re not sure whether it’s been set, you can ask — the backing-field reference :: exposes isInitialized:

val ready: Boolean get() = ::repository.isInitialized

lateinit has real restrictions worth internalizing: it’s var only, the type must be non-null, and it can’t be a primitive (Int, Boolean, and friends), because the “unset” sentinel is null under the hood and primitives have no null. For a primitive you can’t set in the constructor, reach for Delegates.notNull() instead — a delegate that holds a non-null value assigned later and throws a clear error if read too early:

import kotlin.properties.Delegates

class Config {
    var port: Int by Delegates.notNull()
}
// reading port before assignment:
// IllegalStateException: Property port should be initialized before get.

Use both only when you truly control the lifecycle. For everything else, a nullable type is the honest choice, and the operators above make it cheap.

Nullability and generics

A plain type parameter <T> secretly permits null, because its upper bound is Any?. If you write a generic function and don’t want callers passing nullable types, bound it on Any:

fun <T> loose(x: T) {}          // T can be String?  — null allowed
fun <T : Any> strict(x: T) {}   // T is non-null — strict(null) won't compile

This is a common oversight in generic APIs: a signature that looks non-null quietly accepts null because the author forgot the : Any bound. The generics chapter goes deeper; the null angle is worth flagging here because it’s where nullability and type parameters intersect.

The leak from Java: platform types

Here’s the one place the guarantee softens. When Kotlin calls Java, it can’t know whether a returned String is nullable — Java’s type doesn’t say. Kotlin calls this a platform type, written String!, and it trusts you: no forced null check, but a null still crashes at the point of use. It’s the one crack through which an old-style NPE can re-enter.

The defense is to pin the type down the moment a value crosses the boundary, choosing deliberately whether it’s nullable:

val name: String = javaApi.getName()   // assert non-null here — fail fast at the boundary
val name: String? = javaApi.getName()  // or treat it as nullable and handle it

If the Java library carries @Nullable/@NonNull annotations (or a JSpecify @NullMarked package), Kotlin honors them and the platform type disappears — the nullability becomes known and enforced. The Java-interop chapter covers this boundary in full, because it’s where most real-world null bugs in Kotlin actually originate.

Final thoughts

The win isn’t any single operator — it’s that “can this be null?” stops being a question you answer by reading documentation or by crashing in production. The type says it, and the compiler holds you to it. The operators here (?., ?:, as?, ?.let) are the small, ergonomic moves for the cases where the answer is “yes, and I need to handle it,” and the escape hatches (!!, lateinit, platform types) are the places you’re stepping outside the guarantee — each one a spot to slow down, because that’s where the billion-dollar mistake gets back in.

Next, we put these types to work in bulk: collections, where Kotlin draws a line Java never did — read-only versus mutable.

Practice: reinforce this with the companion workbook — short, click-to-reveal problems.