Objects.nonNull()

[Rémi Forax]

On 01/13/2011 11:41 PM, David M. Lloyd wrote:
> On 01/13/2011 04:31 PM, Rémi Forax wrote:
>> On 01/13/2011 11:11 PM, Brian Goetz wrote:
>>> <rathole>
>>> I disagree with Tom here. We have *already* made the billion dollar
>>> mistake, and we can't eliminate that headache (but we can provide
>>> easier access to aspirin.) Java developers are *constantly* writing
>>> methods like the suggested carpet-sweeping nonNull() to work around
>>> this (and some of the Objects methods already do this, like
>>> hashCode()). If I had to guess how many times this exact method had
>>> been written across all the Java code in the world, I would be quite
>>> surprised if its common logarithm were less than 4.
>>> </rathole>
>>
>> I disagree.
>> Propagating null is rare if your API doesn't allow to take null as
>> argument.
>> The only place where you need to propagate null is when you output
>> something like in Swing or
>> in the presentation tier of a webapp.
>> Otherwise propagating null is a mistake because it adds layers between
>> the bug and it's appearance.
>
> I disagree with your disagreement. :)
>
> A null value very commonly means "not found".  Consider such examples 
> as Map.get().  Trying to pretend like null doesn't exist is silly, and 
> trying to pretend that people don't write such methods and count on 
> this functionality is equally silly.  If you don't think people should 
> be using null, say so on your blog; don't enforce your opinion on 
> others through core API changes.

I was not clear. I don't pretend that null doesn't exist.
Carpet sweeping is not a good idea. As you said, null is used as return 
value. I have no problem with that.
I just pretend that the developer has to put an "if" here and not call a 
kind of black magic
function that will only work with 10 lines examples.

>
> I for one like null; I think it is damned handy.  And I think 
> propagating it is just fine so long as it is documented as a part of 
> the contract of the method.  That's an education issue, not a language 
> issue.

By documentation, do you mean you use @Nullable and a null typecheker. 
In that case I agree with you,
otherwise it's rare to see the documentation of a field saying that it 
can be null.
So when you modify something you have to follow the reference backward 
from usage sites.
I hate to do that.

Rémi