Objects.nonNull()

[Ariel Weisberg]

Hi all,

As a user the first name that came to mind was expect. Expect doesn't
imply a specific error signaling pattern, but it does imply that it is
an error if the condition is not as expected. Expect is only one letter
less than throwIf, but it doesn't include a capital letter.

expectNonNull: If the value is null do X where X is some error signaling
pattern that I would have to look up or be familiar with as a Java user.
assertNonNull: Throws AssertionError on null input if assertions are
enabled
ensureNonNull: If the value is null return a non-null value
checkNonNull: Return false if the argument is null and true otherwise

I would be surprised if a method named assert didn't throw
AssertionError, or if a method named check did not return a boolean. I
would expect an ensure method to perform some corrective action if the
named condition isn't met. I do prefer asNonNull over ensureNonNull
because it is shorter and implies that a reference is returned.
expectNonNull does not do a good job of implying that a reference is
returned, and neither does ensureNonNull, but it is clear when read in
the context of code.

java.util.[Expect | Ensure | Assert | Check] does sound attractive.

My 2 cents as a user
-Ariel

On Sun, 16 Jan 2011 21:06 -0800, mark.reinhold at oracle.com wrote:
> > Date: Thu, 13 Jan 2011 19:52:27 -0500
> > From: brian.goetz at oracle.com
> 
> > Mark Reinhold wrote:
> >> 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.
> 
> Okay, got it -- I'd lost track of that side of the conversation.
> 
> > 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.
> 
> Yes.
> 
> > 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.
> 
> Correct.
> 
> > 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.)
> 
> I still don't like checkNonNull.  It checks whether its argument is
> non-null, but then what does it do?  Throw an exception if it is
> non-null?  Throw an exception if it isn't?  Do something else?
> 
> My aversion to checkNonNull naming pattern comes from experience.  Long,
> long ago in a code base far, far away I wrote a big set of unit tests
> using this pattern.  Coming back to it months later I had to read the
> code very closely and keep reminding myself that the checkFoo procedures
> were ensuring the Foo condition rather ensuring nonFoo.
> 
> So I hereby retract my earlier retraction and re-propose the ensureFoo
> pattern.  We already have various ensureCapacity(int n) methods around,
> as previously noted, but ensure is such a broadly useful name that we
> shouldn't limit it only to those cases.  Those existing methods would
> presumably throw exceptions if they can't ensure their postconditions
> anyway, so an ensureNonNull method is not really so different.
> 
> Stepping back a bit ...
> 
> I do think we need to consider, as a couple of people have suggested,
> whether this method really belongs in java.util.Objects.
> 
> The other methods in Objects are closely related to the standard Object
> methods of compare, equals, hashCode, and toString.  An ensureNonNull
> method and similar methods are not.  I could imagine wanting to
> statically import one category of convenience methods but not the other.
> This argues for putting ensureNonNull and its relatives in a different
> class, say java.util.Ensure or java.util.Validate.  That, in turn, is
> something that could wait until 8.
> 
> - Mark
>