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.
I would like to leave room in the namespace to support both of these use
cases:
- I expect non-null, and if I'm wrong, fail
- I expect non-null, and if I'm wrong, sweep it under the rug
The motivation for this change is that we're currently grabbing
nonNull(x) for one of them, using a name that is more suitable to the
other.
asNonNull(x) sounds like the latter to me, since asXxx suggests a
conversion. I'm totally fine with that as the name for the
carpet-sweeping version.
Note that these are the only methods in Objects that throw anything --
the rest of the methods in Object are more of the carpet-sweeping
variety. So the name should definitely reflect that these are
assertions/checks/verifications/preconditions.
Someone suggested assertNonNull(x), and while that sort of captures the
intent, people expect assertXxx methods to throw AssertionError, and it
still may surprise the user on what it does in the common case.
I suppose ifNonNull() is a possible choice, though it begs the question
"where is the else clause"?
Unfortunately brevity is somewhat important here because people will use
this inline, such as in the fooWrapper case, which suggest that
something is going to be left unspecified no matter how we slice.
I'm still liking checkNonNull, mostly because I haven't seen something
better yet. (But nearly all the options are better than the status quo.)
