nus-se-bot
commented
2 years ago Team's Response
Thanks for this bug report.
This bug has been accepted because it is a valid flaw.
However, I've downgraded the severity to low as most households, whom this product is targeted towards:
- would not be editing their text file unless they knew how to use it.
Hence, most users are unlikely to face this problem, and it wouldn't hinder normal usage in the slightest. Furthermore, if the user needed to make the value correct, they could change back the value since our current iteration v2.1 doesn't use doubles. Hope you can accept this severity.
Items for the Tester to Verify
:question: Issue severity
Team chose [severity.Low]
Originally [severity.High]
- [x] I disagree
Reason for disagreement: Thank you for the response! I still believe in the need to filter invalid data types and corrupted user data.
Moreover, stating that target users would not edit the text file might not be as accurate, as the files are for users to edit (Hence, why it is human editable). And stating a warning in the user guide not to tamper with files is still not an excuse for developers not to catch and filter any file-related errors, ie. data corruption.
This was further emphasized in detail by the prof in this issue: https://github.com/nus-cs2113-AY2122S1/forum/issues/144
I decided to mark this bug with high severity as it prevented users from starting the program at all and no filter was implemented for the corrupted data, and no fix was offered by the program. Hence, could cause the product to almost be unusable for users.
As a user, if I update my data manually, and set my quantity as a double (1.5), as I in fact have some half-packet of items in the fridge, this value is not filtered out. No warnings mention in the UG and prevents the program from starting as it throws an exception