Code review: 7012540 (java.util.Objects.nonNull() incorrectly named)
Ulf.Zibis at gmx.de
Wed Jan 26 12:31:05 UTC 2011
Am 26.01.2011 00:33, schrieb Brian Goetz:
>> Since postconditions are labeled "ensures" in the "r/e/m" triad, this
>> method should be named "ensureNonNull".
> Right, there's precedent for "ensureXxx" methods to actually change the state of things to ensure
> the postcondition, such as ensureCapacity() methods in the collection implementations. Given that
> a part of the motivation for this change was to leave room in the namespace for both the
> precondition-enforcing variety (barf on null) and the postcondition-ensuring variety, aka the
> carpet-sweeping variety ("if it is null, make it non-null") ensureNonNull sounds a lot more like
> the the carpet-sweeping version than the version being discussed (barf on null).
The funtionality is:
Check the argument for non-nullity AND return it if the condition holds, otherwise fail by throwing NPE.
"notNullChecked(x)" IMO perfectly describes this behaviour.
As a short cut, "nullChecked(x)" seems clearly enough to me.
It does not block a future ensureNonNull(x) -> convert x to a non-null value if null.
"requireXxx" lacks the fact, that is doesn't specify the positive-case return behaviour. It's more
suitable for a void method/operator as "assert" already does.
More information about the core-libs-dev