>Null Check or Null Object Pattern

>Something I’ve seen a lot in code over the years, no matter which language I happened to be coding in at the time, are checks for Nulls. They end up being scattered through out code for various reasons. The question I have to ask is, with the Null Object Pattern….shouldn’t we be trying to return Null Objects instead of returning NULL when a class is to be returned or a value?

Martin Fowler’s catalog of Refactorings has this as the Introduce Null Object refactoring. I’ve seen it stated as the Null Object Design Pattern as well. Shouldn’t our objects try to be good citizens and not make everybody check for Nulls? The W3C DOM is notorious for returning NULL, and it is one of many reasons it’s not my favorite model to deal with when working with XML. However, this is also spread through out other frameworks as well. It seems we are just shifting the responsibility for our mess from the framework to the implementers that have to deal with all these nulls.

Another excellent resource on this is Tor Norbye’s Code Tip #9.

This entry was posted in eclipse, xml. Bookmark the permalink.

6 Responses to >Null Check or Null Object Pattern

  1. Ismael Juma says:

    >The null object pattern is useful in some cases, but it involves quite a bit of boilerplate and you have to work out what the “do nothing” behaviour is for the various fields (if there is one).In the cases where the return value is optional, Option/Maybe is a good solution and it composes well but it’s yet another feature that doesn’t work so well from Java. James Iry has a nice blog entry on the topic (the comments are also interesting):http://james-iry.blogspot.com/2007/08/martians-vs-monads-null-considered.htmlIsmael

  2. >I have used Options with quite a bit of success. It doesn’t work brilliantly from Java but libraries like Jedi help.Channing

  3. Ismael Juma says:

    >I was not aware of Jedi. Interesting library and nice to see that it includes Eclipse integration for the annotation processing.These days I try to follow the advice given in the FAQ though:”Are You Aware of Scala?Yes. If you can use Scala instead of Java, do so.”

  4. >I think nulls have their place, as Ismael points out.My personal bugbear is all of the OSGi API methods that return arrays. Eg getServices() which returns an array of services matching a filter… but in the event of no matches it doesn’t return an empty array, it returns null…WHY?!? OSGi tries to be economical but they could have had a single constant “Object[] EMPTY = new Object[0]” for the whole API! Because of this you have to wrap every for loop with a null check. Aaargh!

  5. David Carver says:

    >Neil you touched on another pet peeve of mine lately, the use of arrays instead of Lists or Collections. Again for the point that you pointed out, the fact that they aren’t returning an empty array. Personally I like using the size() method to determine whether an array has something or not. Nulls do have their place, but personally I think they should be used less. Catching nulls just moves the responsibility from the framework to the adopter.

  6. AhtiK says:

    >I’m always using null-free return types for collections and arrays. For “not-found” or otherwise empty return objects I will return null and don’t think it’s ugly.Also I don’t think throwing ObjectNotFound type of exception is good for API users (checking for null is faster than handling exceptions, both coding- and performance-wise).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s