bmi command missing catch error

[xiaohan28]

for the first input, /w 63 was used and app did not catch the missing space and incorrect format error for /w64 and vice versa for the second input, where 64 was taken as the weight and /w63 is ignored. Perhaps could handle such errors of multiple inputs regardless of spacing.

[nus-pe-bot]

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

Thank you for raising this issue regarding duplicate or malformed weight inputs using the /w flag. While we acknowledge the discrepancy in how the application handles cases such as /w63 or multiple /w flags without proper spacing, we have determined that this issue does not significantly affect functionality or user experience.

Issue Explanation:
The issue arises when users input malformed or duplicate /w flags — for instance:

• /w 63 /w64: The second weight is accepted, while the first is ignored.
• /w63: This format is not rejected as an error in certain contexts.
  In both examples, the flag syntax deviates from the expected "/w <weight>" format, which assumes a space separator.

Expected vs Actual:

• Expected: Application should detect and reject incorrectly formatted or duplicated /w flags.
• Actual: The application accepts the second value or misinterprets malformed flags depending on spacing and order.

Root Cause:
The parser currently tokenizes inputs based on standard flag spacing and expects a clean /w <value> format. Malformed flags (e.g., /w64) are not currently caught by the parser, especially when followed by a valid second flag.

Bug Classification:
We classify this as a FeatureFlaw, as the system fails to handle malformed or duplicated parameters robustly—this reflects a limitation in the feature’s input validation logic rather than an outright malfunction.

Severity Justification:
We propose maintaining the severity at Low for the following reasons:

• Unlikely User Behavior: It is uncommon for users to deliberately enter multiple weights or omit spaces in flags. Most users follow the usage format provided in help/UG.
• No Functional Breakdown: The application continues to operate, and a valid weight is still parsed in most scenarios. This behavior causes at most a minor inconvenience.
• Edge Case Only: The issue occurs only under specific malformed inputs, not during normal usage.
• Easily Fixable by User: Users who notice a parsing mistake can correct their input without needing app support.

Next Steps:
We acknowledge this behavior and will consider enhancing the parser in future versions to:

• Explicitly reject malformed flags like /w63 without spacing.
• Handle duplicate flag detection and issue warnings where appropriate.

Conclusion:
This issue highlights a limitation in input validation and is classified as a FeatureFlaw with Low severity. While valid, the impact on user experience is minor and does not affect normal operation. As such, we are marking it as NotInScope for the current release, but will consider parser improvements in future revisions.

Thank you once again for your detailed and helpful feedback.

Items for the Tester to Verify

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: The team's justification states that the issue is "NotInScope" because the malformed /w input is "unlikely user behavior" and "minor in impact". However, this interpretation does not meet the official criteria for NotInScope, as defined in the PE guidelines.

According to the PE triaging rules, a bug can only be NotInScope if:

1. It relates to a feature not intended to be supported in v2.1, e.g., deferred in the UG, or
2. The app handles it gracefully, e.g., rejects the input with a clear error message or fallback behavior.

In this case:

1. The /w63 format is not rejected and no errors are thrown (the user believes the input was parsed correctly).
2. The app fails silently, misparsing or ignoring input without notifying the user.
3. There is no mention in the UG that such inputs are unsupported.

Therefore, this is a validation flaw in an existing feature—not a postponed or unsupported one. The user is misled into thinking their input was accepted correctly, violating robustness and clarity standards expected of CLI apps. Thus, this is within scope, as it concerns error handling for an existing command, and the lack of validation directly affects user clarity.

---

❓ Issue severity

Team chose [severity.Low]
Originally [severity.Medium]

• I disagree

Reason for disagreement: The team argues this is Low because it’s an “edge case” and users can “easily fix” the input. However:

1. The issue results in wrong BMI calculations without warning.
2. Users are not told their first input was ignored, nor that their format is incorrect.

This fits the Medium severity definition from the PE guide:

"A flaw that causes occasional inconvenience to some users, but they can continue to use the product."

This input issue does not crash the app, but it does:

1. Violate expected behavior
2. Cause silent logical inaccuracies
3. Requires manual user debugging, which shouldn't be the case.

A user entering /w63 /w 64 might not notice that only one value is accepted or that parsing failed, and they might think that perhaps the average weight was taken. This is a realistic mistake, especially in a CLI context where input errors are common. Since the behavior is unpredictable and silent, it leads to misleading outputs—a clear sign of medium severity.

---