Inconsistent behaviour of delimiters and exceptions.

[TheDinos]

The CLI application uses the "-" character consistently as its delimiter for commands.

This would lead to the expected behaviour of the application to give an exception if the delimiter is followed by an appropriate command character, for instance "m". However, this is not the case as seen below:

In this case, the user is trying to input a manga named "Hi", to an author "someone". However, the application does not throw an error, and instead adds an author named "someone -mHi".

In addition, the user guide explicitly states that if the author's name contains a "-" character, the user should replace it with "--" instead. This means that it should throw an exception message if someone attempts to use the "-" character in the authors name.

Perhaps this issue should be rectified so that the user does not accidentally input wrong author names?

[soc-pe-bot]

Team's Response

We believe that the tester misinterpreted our UG. A valid flag is considered as the whole token that is valid according to our pre-set flags set (i.e. -a or -d), not just - followed by some string. Our parser is able to detect when an invalid flag (such as -mHi) is inputted and it treats it as part of the valid argument that precedes it (i.e. the -a). This allows for the greatest flexibility for users in naming their author names/manga names. This is mentioned in our UG, where strings between valid flags are included (-mHi is not a valid flag, so it is treated as part of the string).

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: After reading the team's response above, I still believe that the current behaviour of the application does not fully align with the flexibility and user-friendliness stated in the user guide.

The -m flag is a valid command operand, as mentioned in the user guide. When the input is catalog -a someone -mHi, the parser treats -mHi as part of the author's name instead of flagging a potential user error. However, this case is ambiguous and can result from two possible user intents:

• The user meant to input catalog -a someone -m Hi but omitted the space.

• The user intended to use --mHi to specify an author's name containing a hyphen.

In both scenarios, the application should detect and handle this ambiguity by throwing an exception and prompting the user with corrective suggestions. This aligns with the stated user guide recommendation that users should prepend offending inputs with an additional dash, which should then be enforced by the program.

Hence, I believe that this issue warrants further consideration. The parser should either flag ambiguous inputs like -mHi as invalid and provide corrective feedback.

---