Objects.nonNull()

[Rémi Forax]

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.

>
> Rising out of the rathole, it seems there is no objection to renaming 
> nonNull() to checkNonNull or ensureNonNull().  I believe this is 
> clearer, and this preserves the opportunity to dive further down the 
> carpet-sweeping rathole later.
>
> One last question for Mark on the ensureXxx() convention: methods like 
> ensureXxx() sometimes mean "make this true" (like ensureCapacity() in 
> collections implementations) rather than "barf if it is not true."  
> I'm willing to go either way (both checkNonNull and ensureNonNull 
> better match the actual behavior of the method than plain nonNull) but 
> we might as well pick the right convention.

I think I prefer throwIfNull() which is explicit.

Rémi

>
> On 1/13/2011 4:12 PM, Tom Hawtin wrote:
>> On 13/01/2011 20:06, Brian Goetz wrote:
>>
>>> Most of the other methods in this class are of the form "do the right
>>> thing if the object is null (or an array)", but this one is "throw an
>>> exception if the object is null." The intent is clear -- it is for
>>> simplifying fail-fast behavior by checking for nullity early -- but the
>>> name is wrong. This is bad for two reasons: (a) it is confusing and (b)
>>> it forecloses on using the name nonNull() for what most people 
>>> expect it
>>> to do -- which is provide a reasonable default.
>>
>> I think this is completely the wrong way around. On encountering a null
>> the right thing is to throw an NPE. Don't make Sir C.A.R. Hoare's
>> billion-dollar mistake worse.
>>
>> Perhaps the carpet-sweeping methods should be renamed, or put into an
>> appropriately named class.
>>
>> Tom