Open Dniv-ra opened 2 years ago
NaN is an undefined number - not considered reasonable user input. deliberate sabotage is not a bug.
Downgraded to Low - deliberate sabotage
Team chose [response.Rejected
]
Reason for disagreement: While NaN might be an undefined number, the thing is it's also a string based input that can go through places where a number is expected. This coupled with the fact that the very next parameter in the expense command after the value is a user defined string would mean if the user were to forget to input the number, the string after which is supposed to be the category will be the input for the expense as there are no dividers to separate the expense amount and the category. This would mean strings like this which can be valid categories end up being the expense and end up causing a problem when saving the data. The problem only showing up when saving also causes much more inconvenience as there is the whole process of splitting costs which means not only is all that work not saved but that the user has to go through the process again.
Team chose [severity.Low
]
Originally [severity.Medium
]
Reason for disagreement: [replace this with your explanation]
The application adds NaN but when it has to save the data the code breaks throwing an exception The NaN here is case sensitive (only breaks for NaN not Nan or nan)