nus-pe-bot
commented
1 week ago Team's Response
No details provided by team.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Program does not handle case when the text file
Steps to recreate the bug: 1)change number of pullup to negative.
Since some of the default data is -1, some user may make a mistake when editing the text file by adding a negative sign before some data. It does not make sense for the number of pull up to be negative. Instead of allowing the user to load obviously incorrect data into the program, maybe you could consider removing the data point or clarifying with the user
[original: nus-cs2113-AY2425S1/pe-interim#211] [original labels: severity.Low type.FunctionalityBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Thank you for bringing this to our attention. We acknowledge that this accepting negative inputs via text file editing results in a nonsensical output, and that there are some lacking precautions against this behaviour in the current user guide, but we feel that this issue is
Not in Scope, for three reasons:1) This issue only arises in the exceptionally rare case that a user goes out of their way to manually edit data via the text file, which is not a condoned action in the UG and is thus implictly done at users' own risk. Note that in this case, they have made the concious decision to not use the respective commands provided within the program that do have safeguards against this error.
2) In the event a user chooses to edit data via the save file, we as developers are not able to provide precautionary messages before, or during the event. Additionally, the amount of work needed to provide a tailored error message addressing the specific variable mismatch would be out of proportion with the rarity of this behaviour bug, and actually reduces the usefulness of the current data loading feature in the event of data corruption, where there may be multiple erronous entries in the save file.
3) There are already existing precautions against some level of data-corruption/malformation in the program that ignore erronous save-files. Evidently they did not catch this case which they should have, but they are already out-of-scope additional precautions given that data editing was not an advertised feature of the program, and thus we do not believe that catching cases such as this - which could be considered user self-sabotage - is in scope.
We appreciate your help in making our program more resilient and user friendly.
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: 
The team has not provided any explanation or conclusive proof as to why the issues are duplicates, and without such justification, I should not need to rebut this claim. However, I believe the bugs are not duplicates because they describe distinct problems with different causes and fixes. Bug #8 causes the program to crash entirely, requiring exception handling to resolve, whereas Bug #9 results in invalid amounts being loaded, which requires validation of the input. These issues cannot be fixed independently, as one relates to error management and the other to input correctness, demonstrating that they are separate and should not be labeled as duplicates.
## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:**  According to the website, to classify a bug as NotInScope, the team need to prove at least 1 of the point (screenshot above). According to point 1 of the explanation, the team claims that "editing data via the text file, is not a condoned action in the UG". I tried searching for keywords such as "edit" and "text" but could not find any mention that we cannot edit the text file. I hope I am not wasting my time addressing a justification that appears to have been made up to change the response type. The bug did not fulfil the second point because the software crashed. According to point 3 of the explanation, the team acknowledges that there is already some code in place to handle "data-corruption/malformation in the program." A simple exception catch in the storage code would provide a graceful failure mechanism, ensuring that the program can recover without crashing. From my perspective, the team did not satisfy any of the point to prove the bug should be NotInScope.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I respectfully disagree with the reclassification of this issue to low severity. According to the website, low severity bugs are defined as those that cause only a minor inconvenience. However, a program crash is far from a minor inconvenience as it completely disrupts the user experience, makes the program unusable, and forces the user to intervene manually (e.g., by deleting or modifying files) to restore functionality. This is a significant issue that impacts the core usability and stability of the program, and it cannot be dismissed as low priority. Moreover, the text file name "saveFile" is generic and likely to overlap with file names created by other programs. If another program generates a file named "saveFile" in the same directory, FitTrack will crash without providing any guidance to the user on how to resolve the issue. This makes the program prone to failure in realistic scenarios outside the user's control. In such cases, users may be left unable to use the program unless they delete or rename the conflicting file something they may not even know how to do because it is not in the UG. Given this, I believe the issue qualifies as a medium severity flaw at the very least, as it causes occasional but impactful disruptions to usability. Crashes fundamentally undermine the reliability of the software, and addressing this issue is essential to ensuring a smooth and predictable user experience.
The program crashes when the text file is corrupted by changing "MALE" to "MAL". Instead of crashing, the program should ignore that line or the entire file