On Fri, 13 Aug 2021 13:16:04 GMT, SkateScout <github.com+919349+skatesc...@openjdk.org> wrote:
> OK even if we keep out the edge case in the try block the > "parseLong(nm.substring(index), radix)" could be replaced as already > mentioned with parseLong(nm. index, nm.length(), radix) I think it already was: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Long.java#L1287 > and in the catch block the idea to throw an "nice" error can be misleading. > since -02147483648 for example would become -2147483648 because the radix is > 8. Yes, it's slightly misleading that the radix specifier gets cropped out, but the error message does include the radix information so it's not a bug technically: jshell> Integer.decode("-01234567890123"); | Exception java.lang.NumberFormatException: For input string: "-1234567890123" under radix 8 > Since per Radix only one String is possible to get through would if not be > faster and more clear to check (compare) if it is the matching string and > return the correct value else throw the error. This is also easy to read and > even if is on the edge avoid substring , concationation and reparsing. It might be a bit faster for that one non-exceptional accepted input, sure. It could also incur a cost on the fast path due increasing the weight of the code. You'd need to carefully measure that the added logic and checks doesn't cause any trouble elsewhere. ------------- PR: https://git.openjdk.java.net/jdk/pull/5068
