Objects.nonNull() (original) (raw)

Rémi Forax forax at univ-mlv.fr
Thu Jan 13 22:31:03 UTC 2011

On 01/13/2011 11:11 PM, Brian Goetz wrote:

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.

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

More information about the core-libs-dev mailing list