RFR 8135248: Add utility methods to check indexes and ranges

[Rémi Forax]

Le 23 septembre 2015 10:12:09 CEST, Paul Sandoz <paul.sandoz at oracle.com> a écrit :
>
>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.

and what about using an anonymous class instead ?

I suppose that the other solution is to special case invokedynamic if the method handle is a constant to avoid to awake the lambda form beast :)

>
>
>>> 
>>> - 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?

Wrapping runtime exceptions in a try/catch is usually a bad idea. Runtime exceptions are raised because of developer mistakes.
In my dream world, you can replace all runtime exceptions by one single RTFM exception without introducing any bugs in your programs :)

And any analysis will fall short because you don't have to propagate runtime exceptions.

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

yes, reading a signature with a wildcard is easier than a signature with a type variable, half of my students just pretend '?' doesn't exist ...

>
>Paul.

Rémi