Objects.nonNull() (original) (raw)

Rémi Forax forax at univ-mlv.fr
Thu Jan 13 23:53:40 UTC 2011

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:

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. 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

More information about the core-libs-dev mailing list