Re: Question on Effective Java Item 27

<hforco@xxxxxxxxxxxxxx> wrote in message
news:1145548622.568432.125550@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

S Perryman wrote:

This is a common problem, specifically that one is attempting to use one
value to convey multiple meanings. So either :

1. define multiple parameters, one to retrieve the outcome of the search,
and the other for the value.

By 'multiple parameters' do you mean multiple methods - or are you
refering to 'out' parameters?

The latter.

Java doesn't have out parameters.

I know.
But I wanted to explain both solutions as the problem is so common.


2. define a result type that holds both parameters

An example of 2 is :

class FDResult
{
boolean found ;
byte[] value ;
}

FDResult findData(Object key)
// post : RESULT.found XOR (RESULT.value == null)

I like this ... particularly as using the two-method approach
(isExistingKey, followed by getValue) would mean that look-up of the
key is done twice.

Correct.


Although I appreciate that this is more explicit than using a null
return value, do you not agree that as long as it was documented that
null return value meant the key was not found, that it would still work
in the same way?

If it is documented so, then the intent is clear.


There is nothing fundamentally different between the following:

byte[] value = findData(key);

if (value == null) {
// key not found ....
} else {
// do something with value
}

and this ....

FDResult result = findData(key);

if (result.found) {
byte[] value = result.value;
// do something with value
} else {
// key not found
}

... other than the fact that the second example is much clearer.

But in general, there are cases where the value required is not an
object reference, but a real value. For example :

int findData(Object key)

What are you going to use as the 'not found' value ??
Or will you rewrite the interface to be :

java.lang.Integer findData(Object key)

so that you can use the null value as 'not found' ??

Because I haved programmed in different prog langs, I try to have a
consistent approach for a problem regardless of the prog lang.

So here it is multiple out parameters, or a suitable result type.
But never null = not found.


It's in this sense that I meant Bloch was wrong in saying that there is
never a reason to return null. Perhaps "there are cases where it is
meaningful to return null, but in all those cases there are other
approaches which are more explicit and therefore preferable" would have
better.

Everything always depends on the context. :-)


Regards,
Steven Perryman


.