RFR 8135248: Add utility methods to check indexes and ranges

[Paul Sandoz]

On 23 Sep 2015, at 01:18, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Paul,
> 
> 
> 
> ----- Mail original -----
>> De: "Paul Sandoz" <paul.sandoz at oracle.com>
>> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoyé: Mardi 22 Septembre 2015 12:40:03
>> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
>> 
>> Hi,
>> 
>> Thanks for all the feedback.
>> 
>> Here is a new webrev:
>> 
>>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/
>> 
>> Changes:
>> 
>> - Move check methods to IndexOutOfBoundsException
>> 
>> - Use BiFunction, rather than a specific exception mapping function.
>> 
>> - Add check methods that do not accept an exception mapping function and
>> throw IndexOutOfBoundsException.
> 
> I still think that you should not use null as Stephen noticed,
> what's wrong with writing checkIndex like this ?
> 
>  int checkIndex(int index, int length) throws IndexOutOfBoundsException {
>    return checkIndex(index, length, IndexOutOfBoundsException::new);
>  }
> 

Because i want to support the simple cases without pulling in indy.


>> 
>> - Add 2 argument constructors to Array/String/IndexOutOfBoundsException, thus
>> allowing support for method refs.
>> 
>> Remi, i left the generic signatures as is, i am presuming there is an
>> advantage to naming T, rather than using a wildcard e.g. IDEs could use that
>> information (although IntelliJ does not appear to do so at the moment).
> 
> I don't get it. Why it's important for an IDE to know that a code throws a precise *runtime* exception. Any codes can throw any runtime exceptions.
> 

It could aid code completion e.g. wrap in try/catch or analysis of what runtime exceptions propagate.

Perhaps this is a rare case, but in general, why loose such information?

Are you concerned that the method signatures look odd in code and in JavaDoc?

Paul.