It would be nice to introduce a Preconditions class (although I am not opposed to continue maturing Objects). I was waiting for the right time for this to be mentioned again (as it was mentioned in the past). Checking indices aren't the only thing we could add; another thing would be a method that throws ISE on failing a check. Lots of code in the wild does that patten: if (!condition) throw new IllegalStateException();
Cheers, Paul On Tue, Sep 29, 2015 at 2:24 PM, Peter Levart <peter.lev...@gmail.com> wrote: > > > On 09/29/2015 06:05 PM, Paul Sandoz wrote: > >> On 29 Sep 2015, at 12:57, Stephen Colebourne <scolebou...@joda.org> >>> wrote: >>> >>> Just to note that an ideal location for this would be on a new class, >>> one that has been discussed before, an "argument checker class". >>> >>> See Guava Preconditions: >>> >>> https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Preconditions.java >>> >>> See Commons Lang Validate: >>> >>> https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/Validate.html >>> >>> See OpenGamma ArgChecker: >>> >>> http://opengamma.github.io/StrataDocs/apidocs/com/opengamma/strata/collect/ArgChecker.html >>> >>> https://github.com/OpenGamma/Strata/blob/master/modules/collect/src/main/java/com/opengamma/strata/collect/ArgChecker.java >>> >>> This was discussed when Objects.requiresNotNull was discussed IIRC. >>> >> FTR here is the discussion: >> >> >> http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date >> < >> http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date >> > >> >> AFAICT there was no objection in principle to such classes. I sense that >> the objection to going that route was due to an increase in scope and as >> such it would overrun it's budget. >> >> >> I >>> still think it would be a great addition to the JDK (as every project >>> has something similar). This issue could be the start, although it >>> would need a few more methods, guided by the examples above. >>> >>> Just a few *more* bike sheds to paint :-) I am concerned i will never >> finish this nor other un/related tasks. >> >> For now I am ok with Objects being that "argument checker class” simply >> because it already has a gravitational pull due to the mass of the existing >> check methods [*]. >> >> Paul. >> >> [*] I believe it is a backwards compatible to change Objects to extends >> from Preconditions and move the existing static check methods to >> Preconditions. That seems like a sleazy trick though. >> > > Yes, but the same could be achieved by just re-implementing those 3 > methods in Preconditions or delegating from Preconditions to Objects - > without strange subtyping. > > I think it's worth introducing Preconditions class. checkNotNull overloads > are equally well suited for Objects as they are for Preconditions, so it's > not wrong to have them in both, while checkIndex and friends don't really > suit any of the existing classes. If I would have to search for them in > among existing classes, Arrays would be the place to look first. List > interface the 2nd. IndexOutOfBoundsException wouldn't come to my mind, as > Exception(s) are usually not homes for logic, neither would Integer which > is to abstract to mentally associate it with array or list index checks. > > Regards, Peter > > >
