Null is Optional

Introduction

Null reference is commonly used to express the absence of value, it has certain drawbacks though in many languages. Let's take a look at the following method:

User findUser(String name)

What happens when that user can't be found? Throwing an exception is not a good option in many contexts (eg flow control). An alternative is returning a null reference, which seemingly fits the purpose well. It has an issue though: the possibility of a null value is implicit, the interface doesn't reveal it. Why is that a big deal? Not null or null requires different handling: eg if user is null do this, otherwise do that. When someone uses that method, things can go wrong in several ways:

• Null check is not performed (hasn't been considered or forgotten) and a NullPointerException will be thrown in some cases
• Time is invested in making sure that implementation never returns a null reference.. Then hope for the best that won't change in the future.
• Null check is done speculatively, even if it's not needed

The cause for these issues is the communication of intent on the interface is lacking. Revealing nullability on the interface avoids these issues.

Some languages don't allow null references by default and have special syntax for marking nullable references. Most languages can't do this - in most cases for compatibility reasons - and support an alternative to address the issue: the option type. Let's take a look at java's Optional for instance.

Optional<User> findUser(String name);

Now the interface communicates clearly that a user may not be present in the result and the client is forced to take that into account:

Optional<User> user = findUser("johndoe");
// user.foo(); compile error
if(user.isPresent()) {
   user.get().foo();
}

With consistent use of Optional, it is possible to establish a powerful convention of avoiding the use of null references. Putting this to the context of a system, it transforms an interface from:

A a();
B b();
C c();
D d();

To:

A a();
B b();
Optional<C> c();
D d();

The client knows c may not return a value, while the others always do (the convention at play here). The compiler will even force the client to handle the optional value c returns. If d becomes optional at some point in the future, all the client code will be forced to conform.

As a small bonus, there is some additional syntax sugar that simplifies code in a lot of scenarios:

Optional<String> foo = Optional.ofNullable(someThirdPartyCodeThatMayReturnNull());
println(foo.orElse("Hey, no value here"));
println(foo.orElseThrow(() -> new RuntimeException("I really expect a value here")));
someThirdPartyCodeRequiringNull(foo.orElse(null));

Conclusion

In most cases avoiding implicit nulls as much as possible can do wonders to a codebase, making it a much safer place to be. Disadvantages? In most cases there aren't, but as to everything there are exceptions. The Optional is a heap object, this needs to be considered in extreme cases. Also there may be specific scenarios where such practice doesn't deliver real value or is impractical. 3rd party code may also force the use of some nullable references.