Hi Brian,
On 09/10/15 13:41, Brian Goetz wrote:
The semantics of require* here was that it should throw if the precondition
is violated. That lead to a different naming direction than the current
use case, in which null is an expected value rather than an error.
Not necessarily - as the requireNonNull*(x, y) will throw if the
resulting value would be null: the method either returns non-null
or throws... In other words it throws if the postcondition
is violated (which the existing require* method also do,
since for those precondition and postcondition are the same).
best regards,
-- daniel
Sent from my iPhone
On Oct 9, 2015, at 11:58 AM, Stephen Colebourne <scolebou...@joda.org> wrote:
On 9 October 2015 at 01:31, John Rose <john.r.r...@oracle.com> wrote:
This leads me to yet another bikeshed color, FWIW:
- T requireNonNull(T) (cf. Optional::get)
- T requireNonNullElse(T,T) (cf. Optional::orElse)
- T requireNonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet)
- T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow)
- T requireNonNull(T,String) (shorthand for common use of
requireNonNullElseThrow)
Note that there is already a new method in JDK 8 not listed above:
requireNonNull(T, Supplier<String>)
As such, I'm not convinced that requireNonNullElseThrow will pull its weight.
I can see the benefits of this consistency of naming. (FWIW, I think
the "require" prefix was a mistake, but that ship has sailed). If this
naming is chosen, I'd like to see all the methods next to one another
in the source file, which involves moving the method added in JDK 8.
Stephen
