Open senwei01 opened 2 years ago
Hi, thanks for the bug report.
response.NotInScope
This appears like an error message specificity complaint at first glance, but upon reflection, I realised this is a surprisingly insidious feature request that will take a lot of effort.
Let's consider how prefixes are parsed in ArtBuddy, and I believe AB3 and basically every other project in this module.
Most parsers have code like this - snippet from AddIterationCommandParser.java
ArgumentMultimap argMultimap =
ArgumentTokenizer.tokenize(args, PREFIX_ITERATION_DATE,
PREFIX_ITERATION_DESCRIPTION, PREFIX_ITERATION_IMAGEPATH, PREFIX_ITERATION_FEEDBACK);
if (!arePrefixesPresent(argMultimap, PREFIX_ITERATION_DATE,
PREFIX_ITERATION_DESCRIPTION, PREFIX_ITERATION_IMAGEPATH, PREFIX_ITERATION_FEEDBACK)
|| !argMultimap.getPreamble().isEmpty()) {
throw new ParseException(String.format(MESSAGE_INVALID_COMMAND_FORMAT, AddIterationCommand.MESSAGE_USAGE));
}
and this is from ParserUtil.java
/**
* Returns true if none of the prefixes contains empty {@code Optional} values in the given
* {@code ArgumentMultimap}.
*/
public static boolean arePrefixesPresent(ArgumentMultimap argumentMultimap, Prefix... prefixes) {
return Stream.of(prefixes).allMatch(prefix -> argumentMultimap.getValue(prefix).isPresent());
}
All our parser commands don't actually know what are the exact fields that are missing. It also doesn't make sense to hardcode it for one feedback field either, (we would get bug reports for being inconsistent and scuffed in our error handling) - we would need to deal with all keywords to be consistent. How would we handle having error messages for specific missing keywords?
Hardcode all the keywords in the parser.
Modify the implementation for ParserUtil and Prefix
ParserUtil.java
that is similar to the arePrefixesPresent()
method, but it now looks through our modified Prefixes to tell us what is missing, for appropriate display.As you can see, this feature request is going to require A LOT OF EFFORT.
We do not have that many prefixes. It even fits nicely in the screenshot - it should be intuitive for the user to tell that the feedback is missing.
Due to the high effort for low value, "rectifying it is less important (based on the value/effort considerations) than the work that has been done already (because it is fine to delay lower priority work until future iterations)." and this qualifies for response.NotInScope
.
We hope this explanation convinces you for our response choice. :P
Team chose [response.NotInScope
]
Reason for disagreement: [replace this with your explanation]
As shown in the picture above, not filling in the f/feedback just results in invalid command without specifying why. I think it helps the users if the error message for this is more specific