Error Messages Lack Specificity in Highlighting Input Issues

[hjungwoo01]

The application's current error messaging system fails to provide specific reasons when inputs are rejected, often stating only that an input is "invalid" without clarifying the exact issue. This lack of specificity can lead to user confusion and inefficiency as users may not understand what needs to be corrected.

I inputted an incorrect date, 2023 Feb 29, which doesn't exist. However, the error message just tells me this: Invalid date format. Expected format is yyyy-MM-dd. When I entered 2023-02-29, it is in yyyy-MM-dd, a better more specific message would be more helpful for the user.

This is the result I got when I typed in the command logadd 3 8 t/ CHECK s/ 2023-02-29 d/ 999 r/ none

[soc-pe-bot]

Team's Response

Error Messages Lack Specificity in Highlighting Input Issues

The application's current error messaging system fails to provide specific reasons when inputs are rejected, often stating only that an input is "invalid" without clarifying the exact issue. This lack of specificity can lead to user confusion and inefficiency as users may not understand what needs to be corrected.

This bug matches the planned enhancement listed in Elder Scroll's DG exactly:

As per CS2103/T guidelines, the bug is labelled as rejected.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: I appreciate the development team's commitment to enhancing error messages as documented in the planned enhancements of the developer guide. This future improvement indicates an understanding of the importance of precise feedback in error messages.

However, the issue I encountered with the input of an invalid date (2023-02-29) falls outside the scope of these planned enhancements. The message received — "Invalid date format. Expected format yyyy-MM-dd." — inaccurately indicates an error with the format of the date, implying that the arrangement of the year, month, and day is incorrect, rather than the validity of the date itself.

The distinction is crucial because the date "2023-02-29" does adhere to the correct format; it is simply not a valid date. Users attempting to correct the error based on the message provided would be misled, as adjusting the format would not resolve the issue.

As indicated in the course website, "Calling an invalid value a 'format error' and vice versa is a severity.Low bug".

This is not a matter of enhancing the specificity of error messages — it is a case of ensuring that the error messages are fundamentally accurate. Thus, I propose that this issue is classified as a feature flaw. A correct error message would significantly improve user experience by providing accurate guidance, which is essential for a feature as commonly used as date input.

---