RFR 8135248: Add utility methods to check indexes and ranges

[Paul Sandoz]

On 23 Sep 2015, at 18:11, Rémi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Because i want to support the simple cases without pulling in indy.
> 
> and what about using an anonymous class instead ?
> 

Not an anonymous one, but i think i know what you mean :-)

Also, i don’t want to impose a null check of the exception mapping function for every call, which would push the null check to when the values are out of bounds, and throwing an NPE in such cases seems mean when one can easily throw IOOBE 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.

It’s not just wrapping but also knowing that such exceptions propagate. For example, a tool might signal that a public method using checkIndex might want also to document the throwing of IOOBE etc.


> 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 :)
> 

Good luck!


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

I tend to prefer the explicit naming (FWIW Valhalla might push us more in that direction), they look fine in source code, it’s the JavaDoc that looks odd to me and that could be fixed.

My main motivation here was not to loose static information. However, as you point out that is of less importance with runtime exceptions. Hmm...

Paul.