RFR 8135248: Add utility methods to check indexes and ranges
pbenedict at apache.org
Tue Sep 29 19:29:09 UTC 2015
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();
On Tue, Sep 29, 2015 at 2:24 PM, Peter Levart <peter.levart at gmail.com>
> On 09/29/2015 06:05 PM, Paul Sandoz wrote:
>> On 29 Sep 2015, at 12:57, Stephen Colebourne <scolebourne at joda.org>
>>> 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:
>>> See Commons Lang Validate:
>>> See OpenGamma ArgChecker:
>>> This was discussed when Objects.requiresNotNull was discussed IIRC.
>> FTR here is the discussion:
>> 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.
>>> 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 [*].
>> [*] 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
More information about the core-libs-dev