Implementation Patterns: a function returns a Date, but it is reasonable that a date won't be found, return null or try to apply the NULL object pattern?

Question

So let's say you have a function that returns a date

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

}

So 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 than to return a null.... However, say in Java, a null date would be one that is cleared and has the year 1970. So what does everyone think is the best implementation pattern here?

Answer 1

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

Answer 2

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...

Answer 3

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();
}

Answer 4

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.

Answer 5

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.

Answer 6

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 ;)

Answer 7

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.

Answer 8

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 ;-)