It's best not to return null from a methods that returns an String type. instead return just empty string "". This will actually avoid extra checking in the calling method. Return variables can be created and initialized with empty (""). If any results constructed in the method, can be assigned to this result variable. if nothing constructed, it might fall on the last instruction that simply return the initialized variable.
Another approach can be using an Static String constant when empty string need to be requited.
It's best not to return null from a method that returns anarray type. Always returning an array, even if the array has zero length, greatly improves the generality of algorithms. If you
anticipate that your methods will return zero-length arrays frequently, you might be concerned about the performance implications of allocating many such arrays. To solve that problem, simply allocate a single array, and always return the same one, for example:
Another approach can be using an Static String constant when empty string need to be requited.
It's best not to return null from a method that returns anarray type. Always returning an array, even if the array has zero length, greatly improves the generality of algorithms. If you
anticipate that your methods will return zero-length arrays frequently, you might be concerned about the performance implications of allocating many such arrays. To solve that problem, simply allocate a single array, and always return the same one, for example:
<code>private static final int ZERO_LENGTH_ARRAY[] = new int[0];</code>This array is immutable (it can't be changed), and can be shared throughout the application.
We can return null in case of returning an Object.
This problem has been solved to the best extent that Java can do, which is poorly, as per Java.
ReplyDeletehttp://functionaljava.googlecode.com/svn/artifacts/2.20/javadoc/fj/data/Option.html
Its better to use a null object pattern.Saves you from a lot o unnecessary checks and gives you the flexibility to change the implementation to return something else if you want later
ReplyDeleteFew important comments i received
ReplyDeleteI do agree with Strings that there are differences with "" and null. Most of the situations they were treated same.
Why Arrays? can it be collections? yes.ofcourse they are based on the scenario again. Even then it's best to return empty collection.
Just one word of warning with preallocating static zero-length arrays. While they seem immutable and safe to share, they are in fact mutable - because of the monitor. I have seen people synchronizing on the returned values... kind of hoping that every user of such collection/array would synchronize on it before reading/modification. And suddenly you have possible point of contention (or even deadlocks if you are really unlucky).
ReplyDeleteI'm still preallocating them and just kicking people who think it is ok to synchronize on arrays/collections owned by different area of code.
There are lots of pre-defined empty array constants in ArrayUtils from Apache Commons Lang.
ReplyDeleteArtur - Personally, I wouldn't use the term 'mutable' to describe the synchronization issue you describe, as I don't believe thats the common usage of the term. A zero length array is immutable, as its state cannot be changed. Whether synchronization then occurs is effectively orthogonal.
The age old argument of "should I return a null from a method" comes down to the caller's handling of the result. If there could be an object coming back, and a null, then the caller must deal with two things. So you've solved that problem by just changing the null to an object with no content. No real win.
ReplyDeleteThe big problem here is that Java has no easy language mechanism like the elvis operator in groovy.