RFR 8135248: Add utility methods to check indexes and ranges

[Paul Sandoz]

On 21 Sep 2015, at 16:45, Remi Forax <forax at univ-mlv.fr> wrote:

> I agree with Stephen.
> 
> Calling the function interface with the name ...Exception seems very wrong to me.
> 

Agreed, need to think of a better name. One solution is to remove it all together :-) see below.


> The convention of ArrayIOOBE or StringIOOBE is to just report the bad index with no further info,
> currently with your code it's not possible to write
>  checkIndex(index, ArrayIndexOutOuBoundException::new).
> 
> so the functional interface for checkIndex should be int -> Object or long -> Object if you change ArrayIOOBE and StringIOOBE to store a long.
> This functional Interface already exists under the name java.util.function.LongFunction.
> 

The friction here is trying to cater for the existing use-cases in the JDK, after a cursory 5 minute search you will find many conventions :-)

From the use-cases i have looked at so far I believe it’s possible to support nearly all with BiFunction<Integer, Integer, RuntimeException> (i started out with that in mind), in some cases a process of elimination can be used for reporting. Other use-cases could be supported with capture.

There is a use-case in AbstractStringBuilder that requires all three values, that is the only one i have found so far in the JDK. I would be interested to know if there are others and also if people are doing that in their own code too.

I would be happy to sacrifice the use-case in AbstractStringBuilder for using BiFunction<Integer, Integer, RuntimeException>, and add appropriate constructors or factory methods on the common exception types for method ref usage.

Paul.

> For the two other methods that checks several index, again the convention is to report the bad index / size, so a LongFunction is enough too,
> yes, it means that you can not check several index at once with things like (a < 0) | (b < 0) but because the semantics you propose is different
> from what is usually done, you will not be alble to use those methods inside the JDK without introducing incompatibilities.
> 
> cheers,
> Rémi