[
https://issues.apache.org/jira/browse/LANG-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199624#comment-15199624
]
Patrick commented on LANG-1205:
-------------------------------
This bug only worked with doubles or floats that have two trailing characters.
The reason is that one trailing character was stripped off the source string
and used for identifying the data type. This left one trailing character in the
substring which was used in Double.valueOf(substring) or
Float.valueOf(substring). Instead, one should use Double.valueOf(source string)
or Float.valueOf(source string), which throws the expected
NumberFormatException.
FYI: Long does not have the same problem because here Long.decode() is used
instead of Long.valueOf().
Pull request:
https://github.com/apache/commons-lang/pull/130
> NumberUtils.createNumber() behaves inconsistently with NumberUtils.isNumber()
> -----------------------------------------------------------------------------
>
> Key: LANG-1205
> URL: https://issues.apache.org/jira/browse/LANG-1205
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
> Affects Versions: 3.1
> Reporter: Daniel Brown
>
> The {{NumberUtils.createNumber()}} method fails to check for multiple
> trailing characters, and as a result, it returns a value even though
> {{NumberUtils.isNumber()}} indicates that it should not. For example:
> {code}
> boolean isNumber = NumberUtils.isNumber("81.5514DD"); // returns false
> Number numValue = NumberUtils.createNumber("81.5514DD"); // returns a Double
> value, 81.5514
> {code}
> I would expect the {{createNumber()}} method to throw a
> {{NumberFormatException}} in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
