Program quietly overwrites invalid save file

[averageandyyy]

I had intentionally removed the delimiters from the save data, leaving only hello as seen. Assuming that this save file format is invalid, the program loads the save file quietly as per normal, giving the impression of a successful load. However, when verified with view --all, we see that the flashcard was not actually loaded (expected since I messed with the data) but what probably should have happened instead is the user is informed of the malformed data.

additionally, at this point, checking the save file again shows it being overwritten with no fields. if there were other flashcards, I assume they would have been completely overwritten as well. This loss of data is significant.

Edit: Only the invalid entry is removed.

[nus-pe-bot]

Team's Response

While I agree with you that there should be some indication when users mess with the storage files, since it does not affect regular operation of the application I think treating it as not in scope is a fair assessment to eventually increase functionality of the program

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: Dear Development Team,

Thank you for your response. I would like to respectfully dispute the classification of this issue as NotInScope for reasons that align closely with those I outlined in another related issue here. Both issues pertain to the critical aspects of data persistency and integrity, which I believe are fundamental to the program’s functionality. I would recommend reading that issue's response first before going through this one.

As noted in the linked issue, data persistency and integrity are core features of this program, directly contributing to its value and utility. Without robust mechanisms to ensure and protect these aspects, the program risks failing to meet user expectations for reliability. In the context of the current issue, the lack of any acknowledgement towards the user of incompatible save data format during file parsing compromises these core features in two significant ways:

1. Loss of User Data: The silent overwriting of improperly formatted entries means that potentially valuable user-generated content (flashcards) is lost without the user’s knowledge. This undermines the program’s utility and risks alienating users who rely on the program to manage their flashcards consistently and securely.

2. Lack of User Awareness and Feedback: By failing to alert the user about improperly formatted entries, the program not only allows errors to persist but also denies users the opportunity to learn from their mistakes. Without feedback, users cannot correct or prevent such issues, further eroding confidence in the program.

Additionally, I would like to dispute the NotInScope classification on the basis of the perceived effort required to address this issue. As mentioned in the linked issue, the team could implement simple data checks during file parsing to validate the save file’s format. For this issue specifically, a minimal enhancement would involve printing an error message to the console/terminal to inform the user of the formatting error. This approach is both trivial and effective, requiring minimal additional programming logic.

For a more comprehensive solution, the team might consider invoking the program’s existing edit sequence when an invalid save data file format is recognised to allow users to address formatting errors interactively as soon as they are detected. Similar to the current implementation of the edit command and sequence, the user could be prompted with options to correct the flashcard entry. This approach leverages the program’s existing logic, classes, and methods, streamlining development and reducing the perceived effort required to address the issue.

While I acknowledge that evaluating the importance of a feature involves some subjectivity, I firmly believe that addressing issues related to data persistence and integrity is critical for a program like FlashBang, whose primary selling point is reliable data management for flashcards.

I kindly ask the team to reconsider the NotInScope classification in light of these arguments. Thank you for your attention, and I look forward to your response.

---