search

ararchch / pe

0 stars 0 forks source link

Incorrect error message when parameter after phone number is mistyped #9

Open ararchch opened 4 months ago

ararchch commented 4 months ago

image.png As visible, fitbook doesn't recognise that the issue is the ee/ rather than the phone number which may throw the reader off. Would be nice to make the error handling target the right issue.

How to replicate:

  1. Run fitbook
  2. type add n/John Dooooe p/98765432 ee/johnd@gmail.com a/John street, block 123,#01-01 nt/john from school
soc-se-bot commented 4 months ago

Team's Response

We understand where the tester is coming from. Indeed it would be useful if users are corrected for minor typos to the command prefix.

However, we are rejecting this for the following reasons:

  1. It's not a bug.

  2. This is intended behaviour.

Unless a new prefix is specified, all text is assumed to belong to the phone number.

Therefore, we chose to reject this bug.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I understand where the team is coming from - the prefixes after the phone number are optional, so if the prefix is incorrect, fitbook will treat it as a phone number and throw the error message.

While I can understand this sentiment as a developer, as a user I do not think that I will be able to justify this. The fact remains that I typed in a command with a valid phone number and an invalid prefix but the system was unable to identify this error accurately, and misled me by saying that the issue was in the phone number.

As mentioned in the big report, this can throw the user off, and the user would spend time trying to figure out what is wrong with the phone number, rather than looking at the prefix. It is not reasonable to assume that the user will be able to dissect the true error from a completely incorrect error message, and I believe that as developers it is our responsibility to consider all such edge cases and make sure they are accounted for.

The CS2103T website also notes that error messages that are not specific to the problem are considered feature flaws. I do feel that this error message completely missed the exact problem so should be considered a featureflaw.

image.png

While it is arguable that this is a feature to be implemented down the line rather than 1.4 (depending on other features implemented in v1.4), I do think that this is an improvement of the product and should not be outright rejected. Hence I disagree with the teams position.

image.png