Objects.nonNull()

[Ben Manes]

Should these checks even be part of java.lang? It promotes creeping in many 
different assertion utility methods throughout the libraries. I personally 
prefer the more flexible Hamcrest style, e.g. assertThat(foo, 
is(not(nullValue()))), which allows extensibility through matchers. However, I 
wouldn't expect either style to be part of the core language.




________________________________
From: Brian Goetz <brian.goetz at oracle.com>
To: mark.reinhold at oracle.com
Cc: core-libs-dev at openjdk.java.net
Sent: Thu, January 13, 2011 4:52:27 PM
Subject: Re: Objects.nonNull()

> 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.)


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20110113/1af85349/attachment.html>