Why We Should Love 'null'

Suppose we are writing an on-line shop application that allows customers to buy products via internet. Suppose also that the shop owner must be allowed to enter a new product without entering a price, because the price is still unknown and will be entered later.

Which approach is better:

1. We don't allow null for the price field because this eliminates the risk for a null pointer error. If the price is unknown, we simply store the value zero (0) in the database.
2. If the price is unknown, we store null in the database and open the door for null pointer errors.

User Jay also says:

How would the web shop behave if we used the second approach, that is to say we use null for product prices not yet entered?

The risk of displaying a price of zero and buying a product for free is instantly eliminated.

We would be required to test for null and display a message like "price not yet available" or "please call us". If we forget to do this, then a null pointer error is thrown. This is undesirable, but much better than letting the user buy a house for free, or - why not - the set of all free houses available on the website.

The risk of calculating a wrong average price is also instantly eliminated.

Again, we would be required to test for null and ignore products with null prices. If we forget it, a null pointer error appears as soon as there is a price with null in the database. But this is of course much better than silently delivering wrong results.

We could easily find more examples of software defects caused by using zero (0) instead of null.

Moreover, we have to be aware that the same problems exist with similar approaches such as:

• using an empty string (or the string "null") instead of null in case of a string value
• using the value false instead of null in case of a boolean value

If our application crashes because of a null pointer error, our customer is unhappy.

If our application delivers wrong results or does other stupid or dangerous things, our customer is very unhappy.

'unhappy' is better than 'very unhappy'.

Hence, we should embrace null and make it our friend and ... love it!

So, what can we say about our introductory example in which we saw that the following code:

String email = null;
System.out.println ( "Alice's email address is " + email );

produces this result:

Alice's email address is null

In this specific case, the result might be acceptable. But the language/compiler shouldn't decide this. As we have seen already, it would be much better to throw a NullPointerException because this would inform the programmer quickly about a problem with the code. null is virtually always a special case and as such it should explicitly be treated as a special case in the source code.

Even in this simple case, the correct solution:

if ( email != null ) {
   System.out.println ( "Alice's email address is " + email );
} else {
   System.out.println ( "Alice doesn't have an email address." );
}

is superior, because saying...

Alice doesn't have an email address.

...is obviously better (more understandable - especially for non-programmers) than saying:

Alice's email address is null

Note

In many cases, Java does throw a NullPointerException (or another exception, like IllegalArgumentException) if an input value is null. For example, let's compare two alternatives: The following code: String s = "foo"; s = s + null; System.out.println ( s ); doesn't throw a NullPointerException, but displays: foonull However, the behaviour is different if, instead of using the + operator, we use method concat in class String: String s = "foo"; s = s.concat ( null ); System.out.println ( s ); Now a NullPointerException is thrown, because method concat doesn't accept null as input.

The Null Object pattern takes the previously described practice - used for simple scalar values - a step further by applying the same idea to composite objects, that is to say objects composed of several data fields and operations.

Instead of using null, a special non-null object is used to represent 'there are no data', thus eliminating the risk for null pointer errors.

Let's look at an example.

Suppose we have the following interface in Java:

import java.io.PrintWriter;

public interface ICustomer {

   public String getName();
        
   public void writeOrders ( PrintWriter writer );
        
}

A standard implementation of this interface would look like this:

import java.io.PrintWriter;

public class Customer implements ICustomer {

   private String name;

   public Customer ( String name ) {
      this.name = name;
   }
        
   public String getName() { return name; }

   public void writeOrders ( PrintWriter writer ){

      writer.println ( "List of orders:" );
      // more code to get orders and write them out
   }
}

And here is another implementation that applies the Null object pattern:

import java.io.PrintWriter;

public class NullCustomer implements ICustomer {

   public NullCustomer () {}
        
   public String getName() { return ""; }
        
   public void writeOrders ( PrintWriter writer ) {
      // do nothing
   }       
}

Now, instead of using null, a shared instance of NullCustomer would be used each time a customer doesn't exist. For example, look at the following method signature:

public static ICustomer getCustomerByName ( String name );

This method would return an instance of NullCustomer (instead of returning null) if there is no customer with the given name in the database.

Because the basic idea of the null object pattern is exactly the same as for practices like 'use zero instead of null', the null object pattern suffers from the same inconveniences and dangers described before: it easily leads to defects that are worse than a null pointer error.

In a comment to an interesting article with the title No more excuses to use null references in Java 8 (and with comments worth reading) user Henk De Boer eloquently describes what can happen:

The Null Object pattern might be useful in some rare situations, but we should be very careful before deciding to use it. For more information, refer to the Wikipedia article and look at the Criticism section which starts like this:

It is also interesting to note that appearances of null objects are virtually non-existent in real life. Such objects would be of little use and lead to funny, bizarre or even dangerous behaviour. Imagine a NullEmployee in real life: You pay him a salary but he doesn't do anything. Or: You buy and eat plenty of NullFood, but it doesn't have any taste and you still feel hungry.

The final conclusion is obvious:

The basic idea of the Optional/Maybe pattern is this:

Instead of providing a non-null value or null, always provide a non-null container object that either contains a value or doesn't contain a value.

You can also think of this container as a list having 0 or 1 elements.

This pattern is used in different languages, with different names for the container type. For example, in Java version 8, in Google's Guava library and in Swift it is called Optional, in Scala it is called Option and Haskell uses Maybe as name.

To understand how it works, let's have a look at a stripped version of the JDK source code of class Optional in Java version 8:

package java.util;

public final class Optional<T> {

   public static<T> Optional<T> empty()

   public static <T> Optional<T> of(T value)

   public static <T> Optional<T> ofNullable(T value)

   public boolean isPresent()

   public T get()
}

The first three static methods are used to create an Optional object:

• empty() is used to create an empty container - the pendant to null.
• of(T value) is used to create a container with a non-null value.
• ofNullable(T value) is used to create a container with a nullable value (i.e. value can be null or non-null).

get() is used to retrieve the non-null value in case isPresent() returns true.

	Note
	There are more methods in Java's Optional class, but they are irrelevant for the discussion in this article.

Now let's have a look at a simple example of how Optional could be used in practice.

Suppose the following method exists - used to find a customer in a database by the customer's name:

public static ICustomer findCustomerByName ( String name ) {
   ICustomer customer = null;
   // code to find customer in database
   // if customer not found return null
}

Obviously, this method can lead to a NullPointerException because null is returned if a customer with the given name doesn't exist in the database.

To avoid this, we can return a non-null Optional<ICustomer> (instead of a nullable ICustomer) as follows:

public static Optional<ICustomer> findCustomerByName ( String name ) {

   ICustomer customer = null;
   // code to find customer in database
   // if customer not found null will be stored in variable customer
        
   // now create an Optional object and return it
   if ( customer != null ) {
      return Optional.of(customer);
   } else {
      return Optional.empty();
   }

   // Note: the above 'if' can be simplified as:
   // return Optional.ofNullable(customer);
}

As we can see, this method never returns null.

If the customer is found, it is stored in the Optional container object.

If the customer doesn't exist, an empty Optional container object is returned.

We would use the new version of findCustomerByName like this:

Optional<ICustomer> customerOptional = findCustomerByName ( "Albert" );

// check if the customer has been found
if ( customerOptional.isPresent() ) {
   ICustomer customer = customerOptional.get(); // get the value stored in Optional
   System.out.println ( "Customer found: " + customer.toString() );
} else {
   System.out.println ( "Customer not found." );
}

If the else branch is not needed we can use ifPresent() and simplify the code:

Optional<ICustomer> customerOptional = findCustomerByName ( "Albert" );

customerOptional.ifPresent ( c -> System.out.println ( "Customer found: " + c.toString() ) );

By looking at the method signature, we can see that an Optional<ICustomer> is returned (instead of simply an ICustomer). This makes it clear that the method returns with an empty Optional in case of 'no data found'. Compare this with the ambiguity of the first version of the method which doesn't use an Optional. In that case, without further information provided by a comment or an annotation, the API doesn't tell us what happens in case of 'no data found'. null could be returned, or a Null Object could be returned or an exception could be thrown. So, knowing that an Optional is returned, we also know that we have to check the presence of data with method isPresent(), before retrieving the value with method get().

Another advantage of the Optional/Maybe pattern is that you can use it in any programming language. If your preferred programming language doesn't provide Optional/Maybe components in the standard libraries then you can simply create your own version and customize it to your specific needs.

Unfortunately, there are a number of considerable inconveniences with this pattern.

	Note
	The following observations are related to class java.util.Optional in Java 8. They don't necessarily apply to variations of this pattern in other libraries or other programming languages.

For more information, refer to this article and don't miss the FAQ and reader comments.

We can conclude:

Under certain conditions the Optional/Maybe pattern in Java helps to prevent null pointer errors. However, some misuses cannot be prevented by the compiler and the pattern requires more verbose code. Therefore a good amount of discipline is required. Another issue is that the wrapper objects create overhead at runtime.

In any case, the Optional/Maybe pattern doesn't lead to 100% null-safety.

Note

Some functional programming languages (the most prominent one being probably Haskell) have been built from ground up with the Maybe monad in mind (which is not the case in Java). In these languages Maybe is consistently used in the libraries (in Java this is done only in new APIs introduced in version 8). In idiomatic source code, pattern matching (which doesn't exist in Java) is used to check whether there is a value or not, and the compiler emits a warning or error when the code doesn't check for 'no data'. Hence, the usefulness of the Option/Maybe pattern depends on how it is implemented and used in a language. Moreover, the Option/Maybe type (or monad) typically provides other useful features such as function composition and map/reduce functionality for collections. However, the compiler cannot protect against misuses and null pointer errors can therefore still occur. Yin Wang puts it like this in an interesting post Null reference may not be a mistake: "After years of using languages both with null pointers (e.g. Java) and without them (e.g. Haskell), I found that null pointers are much easier and more natural to use than its counterparts (e.g. Haskell’s Maybe type)."

if ( expression != null ) {
   // code for 'we have data'
} else {
   // code for 'no data'
}

• Some languages don't have compile-time null-safety, but they have special language constructs that make checking for null and/or avoiding null pointer errors more easy.
  • C# has a Nullable<T> type that is similar to Optional<T> and can be expressed as T?. T can be any primitive value type (int, char, boolean, etc.) or a struct. It cannot be a reference type.
  • F# provides the Option monad. Pattern matching is used in idiomatic F# code to differentiate between 'data' and 'no data', and the compiler emits a warning if either case is not covered - so there is good compiler support. Null pointer errors can occur if F# interoperates with the .NET framework which is largely written in C# and not null-safe, or if the Option monad is not used idiomatically.
  • Fantom has some Null Convenience Operators.
  • Gosu has some null-safe operators used to handle null values in expressions.
  • Groovy has the Safe Navigation Operator (?.) as well as the Elvis Operator (?:).
  • Haskell has the Maybe type. Pattern matching is used in idiomatic code to differentiate between 'data' and 'no data', and the compiler emits a warning if either case is not covered - so there is good compiler support.
  • In Java there are some non-null annotations which are supported by some tools. However, there is no standard for this and different IDEs and tools support these annotations more or less in different ways, as explained in the Stackoverflow question Which @NotNull Java annotation should I use?
  • Swift (Apple's new programming language for iDevices) supports the Optional pattern and provides the ? type suffix as syntactic sugar (e.g. String? is equivalent to Optional<String>).

PPL is an object-oriented, JVM-targeted programming language I created and is still a work in progress. PPL has been specifically designed from the ground up to help writing more reliable code in less time. This goal should be attained by embedding effective Fail-fast! features natively into the language and libraries. A maximum of bugs should be caught at compile-time or else as early as possible at runtime.

Of all the Fail-fast! features natively built into PPL (such as null-safety, Design by Contract, immutable objects, etc.), I consider null-safety to be the most effective feature contributing to more reliable code - for the reasons explained in this article.

The fundamental principle for achieving null-safety in PPL is this:

To see how PPL source code looks like, let's rewrite our initial example in PPL.

The following code asks the user to enter an email address in the system console. If he/she doesn't enter a value (just hits the <Enter> key) then email will be null. The second instruction checks for null and prints an appropriate message.

const nullable string email = system.console?.ask_string ( "Please enter Alice's email address: " )

if email is not null then
   system.out.write_line ( """Alice's email address is {{email}}""" )
else
   system.out.write_line ( "Alice doesn't have an email address." )
.

In the above code:

• The const keyword declares a script constant (i.e. a variable whose value cannot be re-assigned) named email of type string.
• The nullable keyword states that email is allowed to be null. By default (if nullable is omitted) null is not allowed for object references in PPL.
• A Java application can be run with or without a system console. Therefore we must use the so-called safe navigation operator (?. instead of .) after system.console. If no system console is available then ask_string will not be executed and email will be null.
  Note: An improvement in the above source code would be to print an error message if no console is available.
• The check for null (if email is not null) is required. If we omitted it, the compiler would generate an error in the instruction that prints out the email address. This is the key to compile-time null-safety.
• The expression """Alice's email address is {{email}}""" uses PPL's triple quoted string literal which allows us to embed expressions in a string literal between {{ and }}.

	Note
	If you want to try out this example yourself, proceed as follows after installing PPL: Create file null_test.ppl in any directory and with the above source code as content. Open a system console in the directory of the .ppl file you created and type: ppl null_test.ppl

Instead of using an if is null instruction we could also use the if_null: operator which is similar to the so-called Elvis operator (?:) in other languages:

const nullable string email = system.console?.ask_string ( "Please enter Alice's email address: " )

system.out.write_line ( """Alice's email address is {{email if_null: "not yet defined."}}""" )

Now, if email is null, the output will be:

Alice's email address is not yet defined.

There would be much more to say about null-safety in PPL. For more information and examples, please refer to chapter Null safety in PPL's on-line manual.

There is, however, one important point to stress.

Look at the following source code:

var nullable string email = "alice@company.com"
                
if email is not null then
   system.out.write_line ( """Alice's email address is {{email}}""" )
else
   system.out.write_line ( "Alice doesn't have an email address." )
.

We can immediately see that in this case, the check for null is completely superfluous, because at runtime email contains a non-null value and the else branch will therefore never be executed.

The PPL compiler is able to see this too. Internally it uses static code analysis and keeps track of the null-state of all object references.

Therefore, we have to omit the if in the above example and simply write:

var nullable string email = "alice@company.com"
system.out.write_line ( """Alice's email address is {{email}}""" )

This peculiarity also works fine in non-trivial cases such as a variable which is changed several times in complex nested ifs and loops, because the compiler knows the null-state of any object reference in any location of the source code.

It turns out that this distinguishing feature is really useful in day to day programming because situations like the above one appear often in source code. Null-checks in PPL are only required if the null-state of a value cannot reliably be determined at compile-time - for example in case of a value read from an external resource at run-time. Hence, we are relieved from a lot of unnecessary checks for null.

More PPL source code examples and a demonstration of how null-safety helps to write more reliable code in less time can be found in the last part of this article series.

null is an extremely important concept in every programming language.

Although null has caused plenty of bugs, often with severe consequences, we have to be very careful if we use techniques to avoid null (for example the NullObject pattern or the Optional/Maybe pattern), because doing so can lead to outcomes that are worse than null pointer errors.

The best solution is to use a programming language that provides compile-time null-safety and good support for handling null values in the source code. You can then use null as often as needed with no fear of null pointer errors. You enjoy 100% null-safety without any drawbacks, you are more productive and you deliver more reliable software.

Article History

2014-06-19: first version

2014-07-22: added chapter 'Returning an empty collection instead of null'; added F# to list of languages with support for null-handling; added usage of method 'ofNullable()' in Java Optional example

2014-08-20: added note at end of chapter 'The Optional/Maybe pattern'; plus some other small changes in this chapter; added Haskell to list of languages with support for null-handling

2014-11-18: added quote at end of chapter 'The Optional/Maybe pattern'; added links to follow-up articles (part 1 to 4); adapted syntax of PPL examples