3

Supposing I have a function with following signature:

Foo[] getSomeFoos() 
{
      //return null         --- option A 
      or 
      //return new Foo[0];  --- option B
}

What is the recommended practice to return the value indicating there is no elements returned? Any pros or cons for each option?

jjnguy
  • 136,852
  • 53
  • 295
  • 323
pierrotlefou
  • 39,805
  • 37
  • 135
  • 175

5 Answers5

11

If your method GetSomeFoos() actually 'found' 0 elements, then it should return new Foo[0].

If there was some sort of error, you should throw an Exception.

The reason is because users shouldn't have to look for nulls:

for (Foo f: GetSomeFoos()) {
    // do stuff
}

In the above case, if GetSomeFoos returned null, a user will have to deal with an NullPointerException. But, if you return an empty array, the code will never enter the loop, and the user will not have to deal with an exception.

jjnguy
  • 136,852
  • 53
  • 295
  • 323
  • return null might be reasonable. I would use it to mean there are no kind Foo that could possibly be returned. In all other cases, returning empty array is most sensible. – Joshua Sep 28 '10 at 03:21
  • 3
    @Joshua, I suppose I could think of a reason why I could return null. But usually I would return am empty list/array. – jjnguy Sep 28 '10 at 03:23
  • 1
    Whether to return null or empty object entirely depends on the method usage. If this method is called by a client and exposed as an API then throwing exception is better , but if it is used within ur package and never used by client then returning null is ok. – Dead Programmer Sep 28 '10 at 07:47
0

Whether to return null or empty object entirely depends on the method usage. If this method is called by a client and exposed as an API then throwing exception is better , but if it is used within ur package and never used by client then returning null is ok.

Dead Programmer
  • 12,427
  • 23
  • 80
  • 112
0

Returning null is more efficient, since you avoid the overhead of creating a new array or collection object. It's true that you then have to add a null check at the point where you use the function's output, but the overhead for that (in Java and almost all languages) is negligible. I also think that checking for null is a good habit to get into, especially when dealing with third-party libraries.

The downside is that you make the code more verbose.

If you do return an empty array, you can mitigate the performance hit by re-using the same object. Create an immutable constant, and return that:

private static final String[] EMPTY = {};

Or:

private static final List<String> EMPTY = 
    Collections.unmodifiableList(new ArrayList<String>());
Mike Baranczak
  • 8,291
  • 8
  • 47
  • 71
  • 1
    You are arguing the performance gain between: `return null` and `return new Object[0]`? I can't believe that allocating 0 space takes much longer than not allocating any space. (Wait, is there a difference?) – jjnguy Sep 28 '10 at 04:37
  • 2
    Premature optimization is the root of all evil. Don't return null, certainly not for this reason. – Carl Manaster Sep 28 '10 at 04:46
  • There's a big difference. A Java array is an object - it's not like C, where an array is just a pointer to an allocated block on the heap. You need to allocate space for the array object, and initialize it, even if it has zero elements. – Mike Baranczak Sep 28 '10 at 04:50
  • With escape analysis, a fixed-size array could be stack allocated which is more or less a no-op. If you expect the reference to escape a lot (and you can prove the allocations to be a problem), you can store a zero-element array in a static final field and return the same object every time you find zero hits. – gustafc Sep 28 '10 at 06:53
0

I prefer zero-size array.

It's safer(avoid NPE) and easier(no need null check).

卢声远 Shengyuan Lu
  • 31,208
  • 22
  • 85
  • 130
0

From Effective Java (2nd ed) - item 43: return empty arrays or collections, not nulls

In summary, there is no reason ever to return null from an array- or collection-valued method instead of returning an empty array or collection

barrowc
  • 10,444
  • 1
  • 40
  • 53