JDK-4487183 : RFE: Want primitive wrapper classes to be able to test for NumberFormatException
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.3.1,6,7
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2001-08-02
  • Updated: 2024-04-12
  • Resolved: 2021-04-14
Related Reports
Duplicate :  
JDK-6676634 - Numeric classes need static checker methods for Strings
Duplicate :  
JDK-6201013 - Add a static method boolan Integer.isInteger(String)
Relates :  
JDK-4067842 - Float.valueOf() semantic change not for the better
Relates :  
JDK-4705734 - {Float, Double}.valueOf use broken test for whitespace characters
Description
Name: yyT116575			Date: 08/01/2001


java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

The primitive wrapper classes have parsers for String values: e.g.
"Double.parseDouble(String)" and "Integer.parseInt(String)".  If the String
fails to parse, it throws a NumberFormatException.  Unfortunately, handling a
thrown exception can be expensive as far as performance.

I would like to see a method added that would allow the String to be read in
and parsed without needing to test it manually to prevent a
NumberFormatException.

A multi-use method to solve this would be "Double.parseDouble(String, double)"
which would use the double parameter as a default.  The user could put in
Double.NaN as a default to indicate a failure.  "Integer.parseInt(String, int)"
wouldn't have the advantage of a definite non-integer, but if the user knows a
value that will never occur in the input, which is very likely, this would
provide the means to avoid a NumberFormatException, while allowing the option of
using a substitute value.

A simpler (and less useful) method could be "Double.isDouble(String)" or
"Double.canParseDouble(String)" that would return a boolean indicating whether
the parse would be successful.
_______________________________

It has been stated in the "Java Q&A" that exceptions should only be used to
handle error conditions, and never used to control program flow.  Therefore, a
method should be added to allow real-time and time-sensitive applications a
better alternative.
(Review ID: 129232) 
======================================================================
###@###.### 10/28/04 01:07 GMT
Comments
Is a String -> numeric value API were being designed today, returning Optional<NUMERIC_TYPE> would likely be the preferred approach. However, there undesired duplication in functionality to have another set of Optional<NUMERIC_TYPE> methods in addition to the existing ones. Closing as will not fix.
14-04-2021
From an API perspective, having the various String -> Numeric conversion methods return an Optional<Numeric> may be a reasonable way around this design issue.
23-10-2013
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
14-06-2004
SUGGESTED FIX The regular expression JavaDoc for the *specified* set of legal floating-point strings is: 194a195,246 > * <p>To avoid calling this method on a invalid string and having > * a <code>NumberFormatException</code> thrown, the regular > * expression below can be used to screen the input string: > * > * <code> > * <pre> > * String Digits = "(\\p{Digit}+)"; > * // an exponent is 'e' or 'E' followed by an optionally > * // signed decimal integer. > * String Exp = "[eE][+-]?"+Digits; > * String fpRegex = > * ("\\p{Space}*" + // Optional leading whitespace > * "[+-]?(" + // Optional sign character > * "NaN|" + // "NaN" string > * "Infinity|" + // "Infinity" string > * > * // A floating-point string representing a finite positive > * // number has at most five basic pieces: > * // Digits . Digits ExponentPart FloatTypeSuffix > * // > * // In the four sub-patterns listed below, a different > * // subset of the five basic pieces is mandatory. Above > * // each sub-pattern is the corresponding grammar > * // production from the Java Language Specification, 2nd > * // edition, section 3.10.1. The first three sub-patterns > * // are grouped together so the optional trailing > * // FloatTypeSuffix appears after the third sub-pattern as > * // "[fFdD]?". > * > * // Digits . Digits_opt ExponentPart_opt FloatTypeSuffix_opt > * "(((("+Digits+"\\.("+Digits+"?)("+Exp+")?)|"+ > * > * // . Digits ExponentPart_opt FloatTypeSuffix_opt > * "(\\.("+Digits+")("+Exp+")?)|"+ > * > * // Digits ExponentPart FloatTypeSuffix_opt > * "(("+Digits+")("+Exp+")))[fFdD]?)|" + > * > * // Digits ExponentPart_opt FloatTypeSuffix > * "("+Digits+")("+Exp+")?[fFdD]))" + > * > * "\\p{Space}*"); // Optional trailing whitespace > * > * Pattern fpPattern = Pattern.compile(fpRegex); > * if (fpPattern.match(myString)) > * Double.valueOf(myString); // Will not throw NumberFormatException > * else { > * // Perform suitable alternative action > * } > * </pre> > * </code> > * However, with the ccc request being proposed for 4707389, a much simpler regular expression can be used: > * @version %I%, %G% 154a155 > * <dd>SignedInteger 157,173c158,174 < * where <i>Sign</i> and <i>FloatingPointLiteral</i> are as < * defined in < * <a href="http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#230798">&sect;3.10.2</a> < * of the <a href="http://java.sun.com/docs/books/jls/html/">Java < * Language Specification</a>. If <code>s</code> does not have the < * form of a <i>FloatValue</i>, then a <code>NumberFormatException</code> < * is thrown. Otherwise, <code>s</code> is regarded as < * representing an exact decimal value in the usual "computerized < * scientific notation"; this exact decimal value is then < * conceptually converted to an "infinitely precise" binary value < * that is then rounded to type <code>double</code> by the usual < * round-to-nearest rule of IEEE 754 floating-point arithmetic, < * which includes preserving the sign of a zero value. Finally, a < * <code>Double</code> object representing this < * <code>double</code> value is returned. < * <p> < * To interpret localized string representations of a --- > * where <i>Sign</i>, <i>FloatingPointLiteral</i>, and > * <i>SignedInteger</i> are as defined in <a > * href="http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#230798">&sect;3.10.2</a> > * of the <a href="http://java.sun.com/docs/books/jls/html/">Java > * Language Specification</a>. If <code>s</code> does not have the > * form of a <i>FloatValue</i>, then a > * <code>NumberFormatException</code> is thrown. Otherwise, > * <code>s</code> is regarded as representing an exact decimal > * value in the usual "computerized scientific notation"; this > * exact decimal value is then conceptually converted to an > * "infinitely precise" binary value that is then rounded to type > * <code>double</code> by the usual round-to-nearest rule of IEEE > * 754 floating-point arithmetic, which includes preserving the > * sign of a zero value. Finally, a <code>Double</code> object > * representing this <code>double</code> value is returned. > * > * <p>To interpret localized string representations of a 194a196,238 > * <p>To avoid calling this method on a invalid string and having > * a <code>NumberFormatException</code> thrown, the regular > * expression below can be used to screen the input string: > * > * <code> > * <pre> > * final String Digits = "(\\p{Digit}+)"; > * // an exponent is 'e' or 'E' followed by an optionally > * // signed decimal integer. > * final String Exp = "[eE][+-]?"+Digits; > * final String fpRegex = > * ("\\p{Space}*" + // Optional leading whitespace > * "[+-]?(" + // Optional sign character > * "NaN|" + // "NaN" string > * "Infinity|" + // "Infinity" string > * > * // A floating-point string representing a finite positive > * // number has at most five basic pieces: > * // Digits . Digits ExponentPart FloatTypeSuffix > * // > * // Since this method allows integer-only strings as input > * // in addition to strings of floating-point literal, the > * // two sub-patterns below are simplifications of the grammar > * // productions from the Java Language Specification, 2nd > * // edition, section 3.10.1. > * > * // Digits ._opt Digits_opt ExponentPart_opt FloatTypeSuffix_opt > * "((("+Digits+"(\\.)?("+Digits+"?)("+Exp+")?)|"+ > * > * // . Digits ExponentPart_opt FloatTypeSuffix_opt > * "(\\.("+Digits+")("+Exp+")?))"+ > * "[fFdD]?))" + > * "\\p{Space}*"); // Optional trailing whitespace > * > * Pattern fpPattern = Pattern.compile(fpRegex); > * if (fpPattern.match(myString)) > * Double.valueOf(myString); // Will not throw NumberFormatException > * else { > * // Perform suitable alternative action > * } > * </pre> > * </code> > *
11-06-2004
EVALUATION One workaround to this issue would be to use the new regular expression package to test the string's validity; the current JavaDoc for parseDouble and related methods gives the EBNF grammar for legal strings. This could be converted into a regular expression. This regular expression might be a reasonable addition to the JavaDoc; will consider for a future release. ###@###.### 2002-04-24 Working on adding regular expression for valid floating-point strings for 1.4.2; any new methods will have to wait for 1.5 Tiger. Since any floating-point string will convert to some floating-point value, for floating-point only the lexical structure of the string has to be verified. However, the integer string -> value methods will also throw NumberFormatException if the given string is out of range, which complicates a simple syntactic check. In other words, verifying a integer string is valid may involve doing the actual conversion, in which case a method that returned "true" (the string is valid) as well as the converted value would be preferable to one that only returned true/false since in the "true" case the conversion would essentially have to be done twice. ###@###.### 2002-06-27
27-06-2002