views:

155

answers:

5

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?

+11  A: 

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
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
@Joshua, I suppose I could think of a reason why I could return null. But usually I would return am empty list/array.
jjnguy
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.
Suresh S
A: 

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.

Suresh S
A: 

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
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
Premature optimization is the root of all evil. Don't return null, certainly not for this reason.
Carl Manaster
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
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
A: 

I prefer zero-size array.

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

卢声远 Shengyuan Lu
A: 

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