On 17 January 2011 05:26, Brian Goetz <brian.go...@oracle.com> wrote:
>> 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.
I generally use the 'check' prefix for methods that return a boolean.
> I see your point now. Perhaps you'd prefer requireNonNull() for the
> throwing version?
>
> public void fooWrapper(String s, String t) {
> foo(requireNonNull(s), requireNonNull(t));
> }
Both 'require' and 'ensure' are possible, with 'require' being
slightly better in the fluent pattern. However...
> I get your point about maybe we should just remove this, but I do think that
> a method that acts on all object references ignorant of the reference type,
> fits within the mission of juO.
You should definitely remove this now!! Its too late in the release
cycle to be adding a risky method like this one (which to my eyes is
unsuited to the style of the core JDK) whatever you call it.
Especially when many of us really want a
Validate/Preconditions/Assert/ArgChecker class, not this method (I
have used Validate/Preconditions/Assert/ArgChecker to check every
public methods arguments in large codebases for the last 10 years -
its a vital class!)
Stephen
