Thinking some more:
- The name nonNull() is just confusing. It could reasonably mean one
of several things, and we've seen this in people's reactions: some don't
like it for the throwing behavior because its not clear that it has a
strong checking behavior, others don't like it for the defaulting
behavior because the find the defaulting behavior unnatural. This
suggests it is just too vague to make anyone happy.
- I'm still enamored of checkNonNull() for the throwing version but am
still open to better names.
- If we add carpet-sweeping versions later, asNonNull() or
makeNonNull() both seem better than nonNull().
- We just stay away from the not-specific-enough name nonNull() here.
On 1/13/2011 7:20 PM, mark.reinh...@oracle.com wrote:
Date: Thu, 13 Jan 2011 18:15:30 -0500
From: brian.go...@oracle.com
...
Between checkNonNull() and throwIfNull(), I lean towards the former. In any
case the answer should be driven by what is more obvious to the reader.
Agreed.
So
let's look at some typical code:
public Moo fooWrapper(String x, String y) {
return foo(throwIfNull(x), throwIfNull(y));
}
vs
public Moo fooWrapper(String x, String y) {
return foo(checkNonNull(x), checkNonNull(y));
}
Since throwing should be the exceptional path, it feels to me that having throw
in the name sets slightly the wrong expectations. ...
Agreed.
I'm still troubled by the "check" prefix, though. It implies that the
named condition will be tested but it doesn't clearly relate the result
of that test to the method's exception-throwing behavior.
Here's an idea: Why not treat this as a (degenerate) kind of conversion
operation? Call it asNonNull(x) -- it (trivially) converts its argument
to a non-null value, and if it can't then it throws an NPE.
public Moo fooWrapper(String x, String y) {
return foo(asNonNull(x), asNonNull(y));
}
Of all the names we've considered, this looks the most natural to me.
- Mark
