nus-pe-bot
commented
4 years ago Team's Response
As seen here, the format for address is given in the error message when the address format is wrong.
Same goes for email
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: The issue here is that the command's error message is inconsistent in being corresponding to the given prefix.
While true, the team shows that addc n/jackson p/111 a/ gives the corresponding error message for address a/,
it does not follow when there are only 2 prefixes, one n/ and another being any of them other than p/. That is, only p/ will give a corresponding error message when it is the 2nd and only other prefix other than n/.
My issue is justified as follows, with variations to the 2nd prefix (apart from n/):
- If I use p/, an error message specific to phone number appears.
- However, if I use e/, the general error message appears.
- It is similar to the issue in the Point 2 if I use a/, a general error message.
- Similarly, for t/.
Therefore, as you can see, the error messages shown are INCONSISTENT when there are 2 prefixes.
Since this brings inconvenience to the user, who may not understand where he/she is going wrong in their usage of the command, it is marked as a feature flaw. Moreover, I marked this as medium because there are many prefixes, and it is quite common for users to type in wrong prefixes - therefore a need to know exactly which prefix they are getting wrong, rather than trial and error all of them. I believe this follows the following PE guidelines, and therefore my bug issue is justified.
for addc,
the following command gives this error message for p/
However, for a/, there is no specific error message for address.
This makes it inconvenient for the user, who expects address to also have a specific message so they know what the problem in their command is.
The same goes for the other parameters other than for the phone prefix p/