soc-pe-bot
commented
4 months ago Team's Response
Thank you for reporting the issue regarding the lack of exception handling for a corrupted split expenses file that results in the program crashing. While this is a significant issue that definitely requires attention to improve the robustness of the application, classifying it as high severity may not accurately reflect the typical user experience and the conditions under which this bug impacts the software. Therefore, I propose that it be classified as medium severity for the following reasons:
-
Uncommon Scenario: The occurrence of a corrupted split expenses file under normal usage conditions is relatively rare. Files typically become corrupted due to unusual events such as system crashes, hardware failures, or incorrect manual edits. Most users are unlikely to encounter this issue frequently, if at all, during the routine operation of the application.
-
User Control and Prevention: The file corruption leading to a crash, while serious when it occurs, is largely preventable through user education and more robust file handling practices such as validations- before edits and backups. These measures can mitigate the risk of corruption and reduce the likelihood of encountering this issue.
-
Impact on Core Functionality: Although the crash does affect those who experience it, the bug does not impact the fundamental usability of the software for all users. It is a specific error that affects the system only under certain conditions, as opposed to a pervasive or systemic flaw that would compromise the overall functionality or security of the application for every user.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: I feel that this bug is something the team ought to have accounted for in this release and is hence within scope.
The UG pushes for manual editing of files including "SplitExpensesFile.txt" in chapter 6.2. This clearly is an intended feature that does not work correctly.
Course website: response.NotInScope: It is a valid issue but not something the team should be penalized for e.g., it was not related to features delivered in v2.1 or lower priority than the work already doen in v2.1.
## :question: Issue severity Team chose [`severity.Medium`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** The following points are raised in favour of a medium severity: 1) Uncommon Scenario (most users will not encounter this bug, and the bug is unlikely to occur) 2) User Control and Prevention 3) Impact on Core Functionality This are my thoughts about these points and why it should still be high: 1) I disagree that most users will not encounter the bug.  The UG encourages users to manually edit if they are comfortable enough to use the feature. I believe it is fair to say that all normal users, after gaining familiarity with the app, would likely try the manual edit feature. In this sense, with enough time spent using the app, most users will encounter this bug at least once.  Furthermore, with enough time spent using the manual edit feature, it is likely for a crash to be triggered by user input error, since any minor mistakes will throw an uncaught exception. The bug is bound to be triggered by the user by accident during normal usage. Therefore, this is a bug that applies to majority (if not all) of the user base and occurs frequently enough since it is easily triggered by normal usage. 2) I agree that the control measures can help mitigate the effect of the bug, but this does nothing in reducing the severity of the bug. In fact, it is precisely that the uncaught exception is severe enough that there needs to be workaround methods which are barely mentioned in the UG (users were only warned to be careful). The suggested practices to reduce bug occurrence were not mentioned in the UG, hence I feel it is irrelevant in defending the bug. On the topic of mitigation, there is none implemented in the programme. Firstly, there is no exception handling to catch the error automatically. Secondly, corrupt files are not corrected automatically and the app will keep crashing until the user can manually identify and fix his typo, however minor it is. 3) I disagree that it does not impact core functionality because it is triggered by specific conditions. Firstly, it is easily triggered through small unavoidable typos in normal usage in the long run. This applies to the general user and while it is specific to the feature, the conditions while using the feature is easily replicated to trigger the bug. If the bug is caused by a specific character being misused while editing the file, then I believe it is a specific condition. However, this bug can be triggered easily by any typo in the file. The conditions as such are not obscure enough to qualify as a "specific error" under the manual edit feature. Secondly, it does impact core functionality. As per earlier, the programme continues crashing upon startup whenever the bug is encountered and is unusable until the user manually debugs and fixes the programme. This severity is exacerbated by the fact that it is easily replicable. Ultimately, this bug revolves around one sub-feature of the programme, which I feel is the point you guys are trying to drive across and hence should not affect "fundamental usability". However, whenever the bug is encountered (easily), the programme is completely unusable and no other core functions can even be used at all until it is fixed manually. I believe it does indeed compromise fundamental usability in these instances. Hence to sum up: 1) all users are likely to use the buggy feature when they are comfortable with the app. This behaviour is encouraged by the UG 2) The bug is recreated easily from minor accidental typos in normal usage, which in no way makes it an obscure bug that happens in specific conditions, since the condition is just using the feature long enough 3) The app is completely unusable when the bug is encountered. It will just keep crashing til fixed by the user (the app does not fix/detect corruption automatically) I feel that while some points raised by the team are valid points, they are irrelevant in defending this functionality bug and I hope my points do make sense for a major bug that occurs frequently enough and can happen to all users.
When I edit the split expenses file wrongly, the programme seems to lack exception handling for this error and crashes.