Error message for Duplicate Car might not be specific enough

[Domokunx]

A "duplicate car" in this case being another car with the same VRN OR VIN as a car in MATER.

When using the add-car command with a duplicate VRN or VIN, we get the "Car already exists in MATER" error message.

I think a both VRN and VIN should get separate error messages since the user might not know which one is the duplicate field.

For VRN, its a small inconvenience since we can use the find command to quickly search.

For VIN, it would require to go through all the data one by one, using the view command which is troublesome the larger the data set gets. And there is no guarantee that the new car to be added is the typo, or if the user had typo a previously entered data (which they have to now spend time to find).

[soc-se-bot]

Team's Response

Thank you for your feedback. After reviewing it, we have categorized the issue as Not In Scope for the following reasons:

Prioritisation and Effort Addressing this would require a significant redesign of the error-handling mechanism to differentiate between duplicate VRN and VIN cases and present separate error messages. The current implementation is efficient and provides clear feedback that a duplicate exists, allowing users to resolve the typo. Implementing separate error messages would require additional effort, which is less critical than the work already completed for this version. This prioritization ensures resources are directed to more important features.

Supplementary response: In a real-world context, our validation helps the workshop in the event of typos. Furthermore, as VRN and VIN are unique to a single car, oftentimes if one of it matches, then both would match with a specific car. However, we still agree it is still an area of improvement, hence the NotInScope type.

Graceful Handling of the Issue The software handles duplicate entries gracefully by displaying an appropriate error message: "Car already exists in MATER." This message effectively informs users that their input conflicts with existing data. It does not cause the software to crash or fail, meeting the standard for out-of-scope features.

The application assumes accurate data input, and the likelihood of duplicate VRNs or VINs is minimal in practical use cases, as these fields are typically in a 1:1 relationship. In the event that it does occur, we already provide a way to detect these errors and further enhancing error differentiation for such rare cases is not aligned with the current priorities, as it would benefit only a small subset of users while requiring disproportionate development effort.

Hence, according to the rubrics for NotInScope, it is given the tag of NotInScope

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---