The unreasoned Javan

By: on January 17, 2012

I really hate null!

Reflect on that statement. Apparently Tim has a strong dislike for a concept found in lots of programming
languages (even brainiac languages like Haskell) and successfully used in millions of programs. He must be
crazy I wouldn’t like to have a discussion with him about something contentious like tabs versus spaces.

I understand that the world is an uncertain place and that programs need to represent uncertainty but I
don’t think null can be the correct way.

For example, consider this question: how many pets do you own? Is null a suitable answer?

Taking Java as the target for this polemic, which of Integer or int
is the best way to represent the number of pets you have?

Hint, one of those types can’t be null. Bonus question: what happens if you unbox an Integer
that holds a null value? Research topic: why does Java need boxed numeric types?

Some people have told me that they would use a type that can be null because they don’t know how many pets
that I own. Sorry, but I don’t think that is a good answer!

How would your program be different if you let zero be the default value for a quantity instead of null?

If their is uncertainty in a property would it be polite to let me know?

In order to guarantee that your program works correctly do you need to check that every
value is non-null before proceeding?

Is your code very hard to read and comprehend because of the huge number of null checks?

Or do you ignore that because all of your unit tests pass?

You do pass nulls into all your methods via your unit tests don’t you?

Moving on!

Now if we establish that Tim has 23 pets, how do we associate them with Tim?

I’d probably use List<Pet>.

Can a Collection contain nulls?

Can a collection be null?

Should you use null to represent an empty collection?

How would your program be different if you used Collections.emptyList() or
similar instead of null?

Should we stop programming and hope that JSR-305 makes it into the next version of the JDK?

Is their a refactoring in your IDE that will make Tim and his nulls go away?

Is it easier to press generate getters and setters in your IDE because no one you know would
pass in a null anyway at least not whilst you are still responsible for the project?

Do you think Tim is a wee bit upset about nulls in Java code?

Should he go and code in a more modern language?

Not necessarily! Guava can be quite helpful.

You don’t need to use Scala to get an Option type, Guava has Optional

Guava has immutable collections
that reject nulls.

Guava has handy pre-conditions
that you can use to prevent nulls entering at your constructors and setters.

Have I ranted for long enough about null?




  1. Tom Parker says:

    Is Optional just the same as Nullable in C#? (well, in general you only use Nullable for value types as they can’t contain null, but AFAIK there’s no good reason you can’t also use it for reference types as well)

  2. tonyg says:

    Have I ranted for long enough about null?


  3. tonyg says:

    Is Optional just the same as Nullable in C#?

    No, it’s the same as option-types in MLs or Maybe in Haskell. To see the difference, consider that “‘a option option” makes sense in MLs, and “Maybe (Maybe a)” in Haskell, but you can’t have a nullable nullable foo, because there’s no way to represent SOME NONE (or Just Nothing).

  4. Peter says:

    I hate null too!

    ps haskell doesn’t have a null (that I’m aware of) it has Maybe where you explicitly have to check if the value exists before you can proceed.

  5. hok says:

    You know, there’s boolean blindness, and there’s people representing optional values with nulls, and then there’s

    if (x == null) {
    // do something with x
    } else {
    // don’t do something with x.

    Absolutely the bane of the world.

  6. Ben says:

    The problem with null is that it is a subtype of all types (or all reference types) but null is not a subtype according to the substitution priniple so it subverts static type checking. Haskell does have a ‘null’ but it’s use for optionality is frowned upon. Because haskell is lazy you can create a function that will error when evaluated and because it never returns normally it’s result is a bottom type and a subtype of all other types just like languages like Java.

  7. Paul Crowley says:

    Tim considers “undefined” to be the Haskell equivalent of “null”. However the key difference is that you can’t test for “undefined”, so you can’t do any of the evil things Tim talks about. In this sense the only language that doesn’t have “null” is one in which all programs are guaranteed to terminate.

  8. hok says:

    So it’s kind of true, you can’t easily directly test for undefined, but you might find the unamb operator useful when you have two, possibly equal, but possibly undefined values – in a sense, ‘testing for null’.

    Admittedly, it’s a massive hack:
    – the expression (a unamb b) chooses the ‘more defined’ value between a and b;
    – the precondition is that a and b are either undefined, or equal to each other
    – a and b are ‘raced’ against each other on two threads concurrently. (a unamb b) returns whichever finishes first!


    Apparently it’s useful for the semantics of FRP. Whatever, man.

  9. Hubert says:

    Have a look at Spec# (and some papers about it). They have there pretty decent type system that ensures not null safety though it is quite restrictive if you want to do some fancy object initialization.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>