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
>> 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
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.
More information about the core-libs-dev