nus-se-bot
commented
1 year ago Team's Response
Error checking of file
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Improper error handling when storage is given invalid date
When an invalid date is given as in the image above, the date after launch will default to 20/05/2023. Should instead give user error message to indicate an invalid date in the storage file for better error handling.
[original: nus-cs2113-AY2223S2/pe-interim#2812] [original labels: type.FunctionalityBug severity.Low]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
No details provided by team.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [x] I disagree
Reason for disagreement: I don't think that you should be grouping the error handling of different files together. The bug I found is with regards to the fooddict.txt, which you did not handle the error for it. You group my bug under a duplicate of "Improper error handling when storage is given invalid date". In this original bug, the tester modified the date to some extreme value which results in invalid date displayed when the tester enters "wlist" command. Here the tester is modifying the workoutlist.txt file which has a different saving format and data types than fooddict.txt. Hence the error handling for both .txt files will be different, and should not be grouped under a duplicate of one another. Below is the format of your three .txt files:
From the images, the values are separated by commas / colons, and each comma / colon separated values are of different types across different .txt files. For instance, fooddict.txt files has "String:Integer" type at each rows, but workoutlist.txt has "date, string, int, ..." at every row, which is a different format than fooddict.txt with different data types.
Thus, grouping them together is incorrect. This is just like saying hypothetically that I did not handle error for the features of my product, and all feature bugs such as add calories, add workouts, list workouts, etc, are grouped together under duplication of some other feature bug. Which results in me only have one overall bug. Which does not make sense.
Therefore, a better way is to split your error handling for files into three different sub groups, each for different .txt files. Instead of saying you did not check error for files, it should be you did not check error for workoutlist.txt, fooddict.txt, and calorietracket.txt respectively.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** Furthermore, for the bug I found, which is modifying the number to a string. It causes the entire program to crash without any exception handling done. Unlike the original bug that my bug is a duplicate of. The original bug only modified the date in the workoutlist.txt file, which results in wrong date to be displayed in the terminal. This is a serious bug as crashing of program is undesirable and serious. So downgrading the severity of the bug from High to Low is invalid. The program should at least handle the exception for such event and not just crash the program immediately. This makes the program not usable especially when users try to modify the .txt files for quicker population of data to the program. If they were to enter the data wrongly, we wouldn't want the program to just crash without informing the users about the error. Another way is for the program to just ignore the invalid row, and populate the rest of the data into the program.
as shown, when changing the number to a string, the program breaks without exception handling done