RFR 8135248: Add utility methods to check indexes and ranges
Paul Sandoz
paul.sandoz at oracle.com
Wed Sep 23 08:12:09 UTC 2015
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.
More information about the core-libs-dev
mailing list