On 23 Sep 2015, at 01:18, Remi Forax <fo...@univ-mlv.fr> wrote: > Hi Paul, > > > > ----- Mail original ----- >> De: "Paul Sandoz" <paul.san...@oracle.com> >> À: "core-libs-dev" <core-libs-dev@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.
