Objects.nonNull()
Brian Goetz
brian.goetz at oracle.com
Thu Jan 13 22:11:37 UTC 2011
<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>
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.
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
More information about the core-libs-dev
mailing list