> Date: Tue, 25 Jan 2011 15:24:26 -0500
> From: [email protected]
> ...
>
> These methods should be renamed to something that makes its
> checking/verification behavior clear, while preserving the convenient
> self-return property so that it can be used in cases like:
>
> public void fooWrapper(String s, String t) {
> foo(checkNonNull(s), checkNonNull(t));
> }
>
>
> Additional notes: After much discussion on core-libs-dev, the name
> requireNonNull() seemed the least objectionable.
I think requireNonNull(x) is confusing.
For those familiar with the "requires/ensures/modifies" triad of verbs as
a compact way of identifying the preconditions, postconditions, and side
effects of a method or procedure in a comment, a specification, or a more
formal design-by-contract framework, "requires" is just wrong.
When analyzing the invocation of foo in your example, the non-nullity of
s and t are preconditions of foo and therefore postconditions of the
check method. Naming the check method "requireNonNull" suggests that
the check method itself has a precondition that its argument be non-null,
when in fact it's the check method's postcondition which ensures that
property.
Since postconditions are labeled "ensures" in the "r/e/m" triad, this
method should be named "ensureNonNull".
- Mark
