Let's say you have a function that returns a date:

Date myFunc(paramA, paramB){
   //conditionally return a date?
}

Is it appropriate to return null from this function? This seems ugly because it forces clients to check for null.

The "null object" pattern is an implementation pattern that addresses this concern.
I'm not a huge fan of the null object pattern, but yes, it makes sense to always return a list, even if is empty, rather than to return null.
However, say in Java, a null date would be one that is cleared and has the year 1970.

What is the best implementation pattern here?

8 Answers

7
asterite On Best Solutions

The null object pattern is not for what you are trying to do. That pattern is about creating an object with no functionality in it's implementation that you can pass to a given function that requires an object not being null. An example is NullProgressMonitor in Eclipse, which is an empty implementation of IProgressMonitor.

If you return a "null" date, like 1970, your clients will still need to check if it's "null" by seeing if it's 1970. And if they don't, misbehaviour will happen. However, if you return null, their code will fail fast, and they'll know they should check for null. Also, 1970 could be a valid date.

You should document that your method may return null, and that's it.

5
GavinCattell On

null is quite acceptable. However if you want to return null on an error, consider throwing an exception instead.

2
tloach On

If it is possible a date won't be found then the null makes sense. Otherwise you end up returning some magical date (like the 1970 epoch) that will frustrate people hooking into the function far more than just getting a null returned.

Document that it could return null, however...

0
Garth Gilmour On

If its not a performance hit I like to have an explicit query method and then use exceptions:

if(employee.hasCustomPayday()) {
    //throws a runtime exception if no payday
    Date d = emp.customPayday();
}
1
Marc Hughes On

I'm not a fan of the null object pattern.

If null is a valid and intended return value, then return it. If it's caused by an error condition, an exception would make more sense.

Sometimes, the real problem is the method should be returning a more complex type that does represent more information. In those cases it's easy to fall into a trap and return some basic type, plus some special magic values to represent other states.

0
Luk On

Use exceptions if this is not a scenario that should usually happen.

Otherwise, (if this is for example an end-date for an event), just return null.

Please avoid magic values in any case ;)

-1
Chris Cudmore On

You could try using an output parameter

boolean MyFunction( a,b,Date c)
{
  if (good) 
     c.SetDate(....);
  return good;

}

Then you can call it

Date theDate = new Date();
if(MyFunction(a, b ,theDate ) 
{
   do stuff with C
}

It still requires you to check something, but there isn't a way of avoiding some checking in this scenario.

Although SetDate is deprecated, and the Calendar implementation is just ugly.

Stupidest API change Sun ever did.

1
Robin On

It seems like the expected results from this method is a Date, or none found. The none found case is typically represented by returning null. Although some would use an exception to represent this case, I would not (as it is a expected result and I have never been a fan of processing by exception).

The Null object pattern is not appropriate for this case, as has been stated. In fact, from my own experience, it is not appropriate for many cases. Of course, I have some bias due to some experience with it being badly misused ;-)