Closed ong6 closed 3 years ago
@ong6 this may be relevant https://github.com/nus-cs2103-AY2021S2/forum/issues/272
Prof @damithc , #272 talks about invalid JSON itself. What about valid data that exceeds the parameter bounds but the project is not able to handle properly? For example, perhaps some field is limited to positive integer values, but I set it to -100 in the json and the app crashes because of that?
The AB3 stance is (although not explicitly stated), "if you modify the data file, you'd better know what you are doing". Nothing is guaranteed if the user makes a mistake in the data file. While this stance is not ideal, it's still a fair stance and is good enough for the tP. It's great if you handled such 'invalid data in the JSON file' situations. But I don't think we want to enforce it as a requirement or consider it as a bug, especially because we didn't mention such a requirement earlier.
Thanks Prof, missed #272, but just to double confirm,
Bugs based on modifying the JSON file will not be taken into consideration right? So that includes
Bugs based on modifying the JSON file will not be taken into consideration right? So that includes
- Any bugs caused after the JSON is modified
- Any crashes related to modifying the JSON
- Any data corruption caused by modification
Yes, that's right. But if the user updates the JSON file in a way that seems to be correct (based on what the user is expected to know), the software should work. That is, the user should be able to update data by modifying the data file, as it is already a given constraint https://nus-cs2103-ay2021s2.github.io/website/admin/tp-constraints.html#constraint-human-editable-file i.e., the data should be in a reasonably human-editable format
i.e., the data should be in a reasonably human-editable format
For example, if the JSON file contains dates/times, they should be in a format the user can understand and update, not in Unix epoc time format, for example.
Ahh ok, that makes sense, thanks prof!
Most applications will generate a JSON file in the same folder, will modifying it to create "impossible" bugs be allowed?
For example, if an app does not allow duplicates, but if we edit the JSON and manage to get a duplicate, will that be counted?
I personally feel that this should be allowed as an app should be protected from tempering like this: E.g. by crashing. (also defensive programming can be tested)