Notice:

This page has been converted from a dynamic Wordpress article to a static HTML document. As a result, some content may missing or not rendered correctly.

Null Is A Vile Beast ~ Thu, 22 Aug 2013 15:04:48 +0000

Since my last post on Java I have been learning the Spring web framework. The Restlet detour was very enlightening, and I do prefer that framework, but everything I deal with (insofar as Java web applications) at work is based on Spring. So I want to revisit that post from a Spring based approach at some point in the future. This post, however, is about avoiding the use of null.

While working in Java I have developed a renewed love of types. After working in dynamic scripting languages for so long it is refreshing to write code where you know, as you're writing it, the exact representation of the data. Sure, you can institute methodologies to suggest types in dynamic code; but those are easily broken for any reason. For example, this bit of JavaScript:

(function() {
  var aNumber = 0,
      foo = function(){};

  foo = function(x) {
    if (x > 0) {
      return x*x;
    } else {
      return "Invalid number";
    }
  };

  aNumber = foo(2);
  console.log(aNumber); // 4

  aNumber = foo(-1);
  console.log(aNumber); // "Invalid number"
}());

Someone looking at the variable definitions would expect aNumber to always be a numeric value, but someone has come along and given it the possibility of being a string value as well. This isn't necessarily a bug, but it can turn into one fast, and be difficult to track down. Explicitly types solves this problem before the code is ever executed -- it just won't compile. But what does this have to do with null? Let's switch over to Java:

public class NullSucks {
  public static Integer foo(int x) {
    if (x > 0) {
      return x*x;
    } else {
      return null;
    }
  }

  public static void main(String[] args) {
    Integer aNumber = NullSucks.foo(2);
    System.out.println("aNumber = " + aNumber); // "aNumber = 4"

    aNumber = NullSucks.foo(-1);
    aNumber = aNumber * 2; // Null pointer exception is thrown. Program end.
    System.out.println("aNumber * 2 = " + aNumber);
  }
}

As the comments indicate, this program will compile just fine, but it will "crash" at line 15 when it is run. Clearly, we can see that we should expect a numeric value or a null value by reading the implementation of foo and could have coded around it. But if all we have to go on is the method declaration, public static Integer foo(int x);, then we would expect an instance of Integer every invocation. So, returning null allowed us to write a "valid" program, but it is a clear mistake.

We can't get rid of null. It's something we have to live with as a "bad part" of Java. And we will have to deal with it in third-party code that we don't control. But we can avoid using it in our own code.

Google has a rather nice library named Guava. Included in this library is a class named Optional. Optional is merely a container for other types. The benefit of Optional is that it forces you to check for the existence of a value before using it. Let's rewrite the previous example using Optional:

import com.google.common.base.Optional;

public class NullSucks {
  public static Optional foo(int x) {
    Optional result = Optional.absent();

    if (x > 0) {
      result = Optional.of(new Integer(x*x));
    }

    return result;
  }

  public static void main(String[] args) {
    Optional fooResult = NullSucks.foo(2);
    Integer aNumber = (fooResult.isPresent()) ? fooResult.get() : 0;
    System.out.println("aNumber = " + aNumber); // "aNumber = 4"

    fooResult = NullSucks.foo(-1);
    if (fooResult.isPresent()) {
      aNumber = aNumber * 2;
      System.out.println("aNumber * 2 = " + aNumber); // "aNumber * 2 = 4"
    } else {
      System.out.println("invalid result");
    }
  }
}

Yes, the use of Optional has added a few more lines of code, but we have gained a tremendous benefit -- our program works as expected every time. Hopefully you can see from these contrived examples how using Optional will lead to more stable code and easier to use APIs. Of course not all methods need to return an Optional; but if the method has any chance of returning an "absent" (i.e. null) value, I guarantee you will like that method better if it returns an Optional.

As an aside, I'm going to leave you with a Scala example. Scala has this concept built into its core library:

object FooBar {
  def main(args: Array[String]) {
    def foo(x: Int): Option[String] = {
      if (x > 0) {
        return Some("You entered: %d".format(x))
      } else {
        return None
      }
    }

    val bar = foo(42)
    val baz = foo(-42)

    if (!bar.isEmpty) {
      println("bar = `%s`".format(bar.get))
    }

    if (baz.isEmpty) {
      println("baz is empty")
    }
  }
}

Code,  Java,  JavaScript,  Scala,  Technology

Comments