Program crashes do not save data

[Arif-Khalid]

After all my data has been inputted, doing cntrl-C, simulating an unexpected crashed, does not save any of my data.
This is a major bug as it will cause valurable data that the program is supposed to track being lost. This makes the program risky to use for a significant purpose. I suggest saving the data at every command

[nus-se-script]

Team's Response

This is an intended behavior of our program. We decided to only save the data upon exit, which was mentioned in our UG. Hence terminating the program without using the exit command will cause the data to be lost. We save upon exit for efficiency and convenience sake. Rather than saving at every command, we save everything together. But this can be a future improvement for our product, just that for this version, we decided to stick if what we have mentioned above.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Didn't store the information automatically when user close the terminal window unexpectedly

In the UG file, it says only after entering exit, the files will be stored in the txt files. But if the user accidentally close the terminal window, it won't store the information automatically, which is not user friendly. A good practice maybe storing the information each time when the list was modified.

---

_{[original: nus-cs2113-AY2223S2/pe-interim#2518] [original labels: type.FunctionalityBug severity.Medium]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Well. We did mentioned that data is only stored upon exit. And the reason we did that is because of convenience and efficiency sake. Rather than storing the data at every commands, we thought of just storing them upon exit. This is choice that we have decided to follow, and the bug you mentioned is an intended consequence.

Items for the Tester to Verify

❓ Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue response

Team chose [response.Rejected]

• I disagree

Reason for disagreement: I think since it is stated in the UG but is clearly something that you plan on working on in the future, it should be response.notInScope over rejected.

---

❓ Issue severity

Team chose [severity.Medium]
Originally [severity.High]

• I disagree

Reason for disagreement: I think it should be high because it makes the program unusable for its intended use as an expense tracker.

---