Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) (original) (raw)

Ulf Zibis 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). +1

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.

-Ulf

More information about the core-libs-dev mailing list