Open wx-03 opened 2 weeks ago
The observed behaviour is expected when using the parseDouble()
method of the Double
reference type. It only occurs if a user enters deliberately the characters 'd' or 'f'.
We consider it out of scope to safeguard against this special case in the current TP stage, since from our perspective the parseDouble() function handles it quite smoothly. It detects the actual double within the string and ignores the probably mistyped character value. In other words, it corrects wrong user input automatically. As a consequence, the user profile will be equipped with a valid double value and no downstream errors will occur.
Nevertheless, the bug reporter correctly points out that this special behaviour of the parseDouble() method creates a slight inconsistency in the way wrong double input is handled. While the inputs "80.0303f" and "80.0303d" would not require the user to enter a correct double, the input "80.0303e" would require the user to enter a new number. Therefore, future iterations should revisit this part of the user profile creation procedure and add additional safeguards. We thank the bug reporter for bringing this to our attention.
For reference:
$7 ==> 80.0303
jshell> Double.parseDouble("80.0303d")
$8 ==> 80.0303
jshell> Double.parseDouble("80.0303e")
| Ausnahme java.lang.NumberFormatException: For input string: "80.0303e"
| at FloatingDecimal.readJavaFormatString (FloatingDecimal.java:2054)
| at FloatingDecimal.parseDouble (FloatingDecimal.java:110)
| at Double.parseDouble (Double.java:792)
| at (#9:1)
Team chose [response.NotInScope
]
Reason for disagreement: [replace this with your explanation]
Steps to reproduce:
Expected: Weight is rejected as it is not a valid decimal number
Actual: Weight is accepted