Programming Languages – Solutions to Represent Non-Initialized Objects Without Null

nullprogramming-languages

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.

Best Answer

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.

Related Solutions

Error Handling – Should You Check for Null if Not Expected?

The question is not so much whether you should check for null or let the runtime throw an exception; it is how you should respond to such an unexpected situation.

Your options, then, are:

Throw a generic exception (NullReferenceException) and let it bubble up; if you don't do the null check yourself, this is what happens automatically.
Throw a custom exception that describes the problem on a higher level; this can be achieved either by throwing in the null check, or by catching a NullReferenceException and throwing the more specific exception.
Recover by substituting a suitable default value.

There is no general rule which one is the best solution. Personally, I would say:

The generic exception is best if the error condition would be a sign of a serious bug in your code, that is, the value that is null should never be allowed to get there in the first place. Such an exception may then bubble all the way up into whatever error logging you have set up, so that someone gets notified and fixes the bug.
The default value solution is good if providing semi-useful output is more important than correctness, such as a web browser that accepts technically incorrect HTML and makes a best effort to render it sensibly.
Otherwise, I'd go with the specific exception and handle it somewhere suitable.

DAO Methods – Should ‘Consider Returning Null Object’ Apply?

In "Effective Java" item 43 p. 201, Joshua Bloch says, "There is no reason ever to return null from an array- or collection-valued method." He recommends returning a zero-length array or an empty collection (Collections.emptyXxx) when there are legitimately no results. For one thing, it's a pain for the client to double-check everything:

if ( (retVal == null) || (retVal.size() < 1) ) {
    ...
}

Before returning null, ask yourself if the null return value is a result of a programming error on the part of the calling code. Such a check is generally done in the first few lines of a procedure as a defensive check for invalid input values and could legitimately result in throwing an unchecked exception instead of returning null. For my reasoning on this, please see the Checked vs. Unchecked Exceptions entry in my blog.

Scala and Haskell avoid returning null with an Option class. I don't immediately see how this is better than null (other than being type-safe just for the sake of it), but I thought I should mention it as another point of view:

val nameMaybe = request getParameter "name"
nameMaybe match {
  case Some(name) =>
    println(name.trim.toUppercase)
  case None =>
    println("No name value")
}

Bloch suggests that null is an appropriate return instead of an empty collection in C because array lengths are stored separately from arrays and there is no advantage to allocating an empty array. But a null is not the right answer all the time in all languages.

Best Answer

Related Solutions

Error Handling – Should You Check for Null if Not Expected?

DAO Methods – Should ‘Consider Returning Null Object’ Apply?

Related Topic