Null safety — the billion-dollar mistake

A mistake worth a billion dollars

In 1965 a computer scientist called Tony Hoare added a small feature to a language he was designing: a value meaning nothing here. He called it the null reference. It was easy to implement, so he put it in.

Forty-four years later he stood up at a conference and apologised for it. His phrase was the billion-dollar mistake — his estimate of the damage it had done in crashes, security holes and lost work since.

He was not exaggerating. Open any app store review page and read the one-star reviews. "Crashes when I tap save." "Closes as soon as I open it." A very large share of those are one specific bug, and it has a name.

This lesson is about that bug, and about why the language you are learning has largely killed it.

Why null exists at all

It would be tempting to say "just never have nothing". But nothing is a real, honest state of the world:

• A player has not chosen a nickname yet.
• You searched the list and there was no match.
• You looked up a key that is not in the map — exactly what happened in Lesson 1.11.
• A note has not been saved yet, so it has no database id.

The tempting alternatives are worse. Using 0 for "no score" makes a genuine zero indistinguishable from a missing one. Using "" for "no nickname" means an empty nickname and no nickname look identical.

null is the honest answer. The bug was never null itself. The bug is forgetting that something might be null — and then asking it a question anyway.

What a NullPointerException actually is

A name in your program does not hold a whole object. It holds a pointer — an address where the object lives. null is the address of nowhere.

When your code says name.length, the phone follows that address to ask the object how long it is. If the address is nowhere, there is nothing there to ask. The processor cannot invent an answer, so it throws an exception. Unhandled, that closes the app.

Here is the real thing, straight out of Logcat:

1java.lang.NullPointerException: Attempt to invoke
2virtual method 'int java.lang.String.length()'
3on a null object reference

Read it slowly and it is almost friendly. Something tried to call length() on a String, and that String was null. The stack trace underneath tells you which line of which file. Usually shortened to NPE, and it is the crash you will meet more than any other in other people's code.

Kotlin's fix: one type becomes two

In Kotlin, every type you have met so far comes in two versions.

1var name: String = "Ada"
2var nick: String? = "Ada"

String can hold text. String? can hold text or null. That single question mark is the whole idea, and it changes what the compiler will let you write.

1name = null   // does not compile
2nick = null   // perfectly fine

The first line fails with:

e: Null can not be a value of a non-null type String

And this is the part that matters: you now find out in the editor, before the app is built, instead of on a stranger's phone six weeks later. That is what null safety means. Kotlin has not made null disappear. It has moved the discovery of it forward in time by about six weeks.

A type with a question mark is called a nullable type. One without is non-nullable, and the compiler guarantees it can never be null. No check needed, ever.

The four tools

1. ? on the type — "this one may be empty"

You have just seen it. Only add the question mark when a value genuinely can be missing. A nullable type is a promise to every future reader that they must handle the empty case, so do not hand it out for free.

2. ?. — the safe call

You cannot write nick.length, because nick might be nothing. Try it and you get the error you will see most often in this lesson:

1e: Only safe (?.) or non-null asserted (!!.) calls are
2allowed on a nullable receiver of type String?

The safe call is a dot with a question mark in front:

println(nick?.length)

It means: if the thing on the left is null, stop and produce null; otherwise carry on. So with nick = "Ada" this prints 3, and with nick = null it prints null — no crash either way.

The catch is that the answer is now Int? rather than Int. Safe calls pass the nullability along the chain, which is honest but does need dealing with. Which brings us to the best tool of the four.

3. ?: — the Elvis operator

Two characters that mean "or else this instead":

1val letters: Int = nick?.length ?: 0
2println("Hi, ${nick ?: "stranger"}")

If the left-hand side is null, the right-hand side is used. Note the type of letters: plain Int, no question mark. The Elvis operator is where nullability ends — after it, you are back on solid ground.

It is named after Elvis Presley. Turn ?: sideways and you get the eyes and the quiff.

?: is not limited to values, either. This is a very common shape in real code:

1fun show(nick: String?) {
2  val real = nick ?: return
3  println(real.uppercase())
4}

Get me the nickname, or give up and leave the function now. After that line, real is a plain String for the rest of the function.

4. !! — the promise you should almost never make

val letters = nick!!.length

Two exclamation marks. It means: compiler, I am certain this is not null; stop asking.

And if you are wrong, the app closes.

And one bonus: the compiler is paying attention

You do not always need an operator. Plain old if works, because of a feature called a smart cast:

1if (nick != null) {
2  println(nick.length)
3}

Inside those braces, nick is treated as a plain String — no ?. needed. The compiler followed your check and drew the obvious conclusion. This is often the most readable option when you have several things to do with the value.

1Hi, Ada
2Letters: 3
3Loud: ADA
4Hi, stranger
5Letters: 0