If null is a billion dollar mistake, what is the solution to represent a non-initialized object?

Question

This comes with a debate with my colleague that I'm using null as an object initial state.

type Value = Node | null
const [value, setValue] = React.useState<Value>(null)
function test(v: Value) {
  if (value === null) // Do something
  else // Do something
}

I'm curious if null is a mistake in this case. What alternatives are there to represent an object that is not (yet) initialized? And how is this solved in languages that don't support null pointers?

Note: This question is similar to If nulls are evil, what should be used when a value can be meaningfully absent? - the difference is that that question is about cases where a value is truly absent/not relevant - whereas here the question is about a value where initialization has been delayed, because the value will be produced/retrieved later.

Answer 1

The problem isn't null itself. It's the implicit nullability of all object references, as is the case in Java, Python, Ruby (and previously C#, although that picture is changing).

If you have a language where every type T really means T | Null. Suppose you had a system that takes such a nullable reference at its entry point, does some null checking, and wants to forward on to another function to do the "meat" of the work. That other function has no possible way to express "a non-null T" in Java (absent annotations), Python or Ruby. The interface can't encode its expectation for a non-null value, thus the compiler can't stop you from passing null. And if you do, fun things happen.

The "solution" (or "a solution", I should say), is to make your language's references non-nullable by default (equivalently, not having any null references at all, and introducing them at the library level using an Optional/Option/Maybe monad). Nullability is opt-in, and explicit. This is the case in Swift, Rust, Kotlin, TypeScript, and now C#. That way, you clearly distinguish T? vs T.

I would not recommend doing what you did, which is to obscure the nullability behind a type alias.

Answer 2

Great question, many developers wouldn't even think or care about! keep thinking and asking!

You are probably looking for optionals. Here, for example, in TypeScript that you use:

http://dotnetpattern.com/typescript-optional-parameters

The idea is to have explicitly state:

• A) if an object can be null or not
• B) unwrapping nullable objects before using them to avoid null pointer exceptions (NPEs)

The TypeScript parameter example I linked does not really do B)

if (address == undefined) {
  // Do something with a
} else {
  // Address not found, do something else
}

Maybe you can find a better way in TypeScript like it is done in Swift:

if let a = address {
  // Do something with a
} else {
  // Address not found. Do something else.
}

Or Kotlin:

address?.let { a ->
  // Do something with a
} ?: {
  // Address not found. Do something else
}()

The difference is that in the TypeScript example above you can still forget the check and just address, leading to an NPE. Optionals like in Swift or Kotlin will force you to first check the value existence before you can use them.

A common mistake done then is to force unwarp the value because you think the value always exists:

address!.doSomething() // In Swift
address!!.doSomething() // in Kotlin

If you see code like this, run! Usually a value is an optional for a reason, so just skipping over that safety-measure and claiming "there is a value, I am sure" leads you back to the old NPE-coding we try to get rid of.

A quick search looks like you are not really able to do that in TypeScript without voodoo:

Is it possible to unwrap an optional/nullable value in TypeScript?

Answer 3

You should never have a non-initialised object (with the single exception of a short interval of time while you are initialising the object). Null specifies the absence of an object.

The problem is not null pointers. The problem is that in older languages

1. You cannot specify that a pointer cannot be null,
2. You cannot specify that a pointer can be null, and
3. If a pointer is null nothing stops you from accessing what it points to, resulting in a crash or worse.

This results in case 1 in unnecessary code to check for null pointers and handling them, and no compiler warning if a null pointer is assigned, in case 2 in incorrect assumptions that a pointer would be non-null when it isn’t, and in case 3 it crashes.

Answer 4

There are many factors that contribute to null being a "Billion Dollar Mistake". Based on your comments, you're looking specifically at TypeScript and the type of possibly-uninitialized values, so I'll boil it down to two key problems: type safety, and value semantics.

The key - a.k.a., tl;dr

Especially in TypeScript, null-ish values are perfectly valid so long as you assign a simple, clear meaning to it ("no value"), and so long as the language supports this by only permitting null-ish values when the type explicitly allows it.

TypeScript naturally guards against accidental null values.

Others have covered type safety, but the key here is that, in TypeScript, you can include or exclude null and undefined as valid values of a type. At least in strict mode, number, number | null, and number | undefined are all separate types. Types are mathematical sets of valid values, and number only covers numbers. That means that (barring any deliberate breaking of the type system), you don't have to worry about a value unexpectedly being null or undefined. The compiler won't let you accidentally do that. In that regard, the type safety of null-like values is not such a big deal in TypeScript, which just leaves semantics.

So what do null and undefined mean?

In short, they mean "no value" - nothing more, nothing less. The number type can be any number, but it must be a number. In some cases, you want a type that's "a number, or nothing" - that's where you might use number | undefined. If you want something other than "has a value or doesn't" - such as "technically a value, but invalid" or "there was an error trying to compute the value", you need to use something other than null or undefined. The exact solution depends on the exact use case - over-generalizing is what caused the problem in the first place!

So why are there two?

This illustrates the "semantics" problem of the Billion Dollar Mistake quite well! Your colleague was right to point out that, in JavaScript, undefined means "was never defined", and shouldn't be allowed after initialization. That leaves null to mean... anything else that isn't a real value? However, TypeScript is not JavaScript! Believe it or not, the team who creates TypeScript (which is, itself, written in TypeScript) does not use null at all! These experts in the topics of language and especially of TypeScript and JavaScript have decided that null does not provide any value above and beyond undefined. But they do use undefined.

I don't want to misrepresent them, but I believe that this is because they're focusing on what those values mean above and beyond how the JavaScript engines use them. Now, undefined simply means "no value". They don't want to add any more than that, so they don't recognize a difference between that and null.

What does this mean for my example?

There's some missing information about what null is supposed to mean, but you seem to be doing the right thing. However, I would ditch the type Value = Node | null and also switch to undefined. Something like:

const [value, setValue] = React.useState<Node | undefined>()
function test(value: Node | undefined) {
  if (value != undefined) // TS knows v is a Node, not undefined
  else // TS knows v is undefined
}

Bonus: ? operator vs explicit undefined

You can use ? when declaring a value's identifier to suggest that it's optional. This automatically means it can be undefined (as that is the default for when a value is not provided), but it means more than that. function test(value: Node | undefined) means "test requires one argument, which may be undefined", whereas test(value?: Node) means "test can be called with 0 arguments, or with a Node, or with undefined". It's a small difference, but sometimes you want to say "you must tell me what it is, even if you tell me there's no value", in which case you should avoid ?.

Answer 5

It seems you are using TypeScript, is this correct? TypeScript has proper support for nulls in its type system (option strictNullChecks), so using null to indicate a missing or un-initialized value is perfectly fine. (Of course it it always best to avoid uninitialized values in the first place, but that is not always possible.)

The thing about the Million Dollar Mistake is really a misunderstanding. The mistake, as described by Hoare, was to have nulls be a possible value for any reference type. This is the case in Java and some other languages, but is not the case in TypeScript.

In TypeScript nulls are not a member of any object type but is rather a separate type of its own. So there really is no such thing as a "null reference" in TypeScript. More imporatantly, this means nulls are explicit in the type system, so you always know if a value can be null and you have to check for it.

Answer 6

Just don't allow null values.

Require initialization when declaring a reference variable and do not allow to assign null to a reference later.

When a developer actually has a legitimate reason to assign a value which represents the absence of a value (rather the exception than the norm in real world software development), then there are two options.

• They can assign a Null Object. A Null Object is a placeholder object which represents no value, but implements the full interface. So if anyone calls a method or accesses a field of the Null Object, the developer is obligated to implement what is supposed to happen in that case (a no-op, return a placeholder value, or throw a more specific exception).
• They can use the Optional pattern. An Optional is a type which contains either an actual value or doesn't. The actual value can usually be accessed in various ways, but every way requires to state what's supposed to happen when no value is present (again: do nothing, return a placeholder or throw a specific exception). Programming such a class in such a language would of course be impossible without also implementing a null-object, which you are then not going to use. So you would either require Optionals to be a part of the language syntax (like nullable types in Kotlin) or add some additional syntax which allows you to create nullable types without creating null-objects (like the None type in Rust which can be used as one possible option of a heterogeneous type)

Answer 7

Most of the dangers associated with null stem from the way common C implementations treat it. In languages where attempts to dereference a null pointer are routinely trapped, a null pointer/reference may cause a program to rudely terminate as a consequence of trying to process uninitialized data, but such termination would have been the norm in strongly-trapped languages with or without null. The problem is that the way C handles pointer arithmetic makes it expensive to ensure that code won't inadvertently take a null pointer, apply an offset to it, and end up with a pointer which is meaningless but is no longer recognizable as a null or invalud pointer. Attempting to access such a pointer might shut down a program, but it may also corrupt data without shutting down the program, thus allowing the corrupt data to replace what would have been good data on disk.

Answer 8

Dealing with temporary nullity during initialization is not yet a solved problem, but there are solutions. Kotlin has a few options built in to the language. One is to declare a member variable lateinit. This allows one to run one's initialization process with more flexibility. Under the hood, the variable is actually null at first, but later, null checks are not necessary.

Another technique is to delegate a member property (either variable or constant) to a Lazy object, which is accessed when the member property is accessed. Lazy wraps a value, and when accessed, blocks until it's available. The Lazy class is in the standard library, but the by keyword (which declares the delegation relationship) is language-level, and allows for you to use a class other than Lazy, so this option might be good for cases where you need a lot of flexibility in your initialization process.

Although these answers are Kotlin-specific, they are patterns that can be used in other object oriented languages.

Answer 9

Initialization was not delayed since you initialized variable with null.

In JavaScript one can leave variable in undefined state. (Maybe your co-worker likes it more than null state.)

Then go you for

if(value)
  …
else
 … 

That perfectly evaluates for null and undefined.

If something is mistake, it is usually shortly removed. With exception for trivial cases like HTTP referer header field name.

For no-null languages see answer for Are there languages without “null”?. Choose some and educate yourself.

One can truly never avoid no-value state. When data comes from network you cannot tell “oh its int = 0, so it’s nothing” since it is azimuth.

For instance C# nullable annotation context solves in fact nothing. It’s just annotation that brings in not little amount of agenda. To warrant analysis originating from it is valid is at least of same difficulty as it was before to warrant that dereferenced variable is not null all the time.

That is since it is just annotation. It guarantees no thing.

See Known pitfalls for further reference on another “salvation failure” of nullable reference types.

---

“Null References: The Billion Dollar Mistake“ mean technically nothing. You can for instance check nuclear plant or even space shuttle accidents. Even the most verified technical ways can fail. Nobody doubt that money in terms of remittance means not much in such cases.

---

Usually world is not blackwhite stream. Optimistically said nullable annotation machinery has potential to solve things at cost of heaviness

Apparently, if null does not exists in language, there can be no problems about invokes on it etc.

Answer 10

Nullability is not the billion-dollar mistake. Useless programmers who don't validate inputs, are.

Languages or programs that attempt to "solve" the nullability "problem" by introducing monads or optionals or whatever they want to call them, are merely obfuscating the issue of lacking input validation behind an extra layer of abstraction. Essentially, they're trying to do useless programmers' jobs for them.

But that doesn't actually help anything at the end of the day, because a program that doesn't validate its arguments is going to misbehave regardless of whether it receives null or MonadOrOptionalOrMaybeOrWhateverNameYourLanguageThinksIsCool<MyClass>.Default. At least with nullability, you'll get a crash or at the very least a distinctive stack trace; with a monad, your app just won't do what you were expecting it to. Which one of these cases is easier to diagnose and fix?

Ensuring your program runs correctly is your responsibility as the programmer, not the language's. Verify your damn inputs.