joseph31416 / ped Goto Github PK

Command:
cluster 1 a/clem d/Cov

From the first screenshot, there clearly exists a person with "Covid" living in "Clementi". However, the cluster command fails to identify that the cluster exists.
This might be caused by the string matching process being unsound. Different variants of the command like cluster 1 a/Clem d/Cov and cluster 1 a/clem d/cov have been tried and all of them failed to identify the cluster.

When read @!*() is run, an unhandled error is thrown and no error message is provided in the GUI.

This is probably caused by not catching the error thrown by the validator.

When find con/ is run, an empty list is returned.

Given that there are no conditions, shouldn't the entire list of people of no conditions be returned instead?

Command:
update S1234567 hp/91234567 e/[email protected]

Instead of saying that the command format is invalid, a better error message would say that the NRIC field is invalid.

Command:
deleteinfo S1234567A con/

There should be a line break between "info:" and "Name:" in the first line.

Command:
check asd

This is probably caused by not catching the validation error thrown by the validator.

Command:
update S1234567A hp/11111111 e/[email protected] con/

When no input is given for the condition field, the program stores an empty string instead of a null.

It might be a better idea to standardise across the program to determine if empty inputs are considered as null or something else.\

This has potential consequences for the find command.

After find a/ is run, an exception is thrown and it is unhandled.

A simple fix is to catch this exception and return a valid error message to prompt to user to provide inputs.
Another point to consider is whether this should return the whole list of people with all addresses since the address condition is empty.

Command:
cluster 0 a/Serangoon d/DENGUE

When a cluster size of 0 is given, an error about the validity of the cluster size should be raised, not about the command format.
This is probably caused by insufficiently distinguishing the exception thrown by the command input validator.

The following create command does not work with this input, taken directly from UG

create ic/S0123456A n/Jane Doe hp/87654321 a/311, Clementi Ave 2, #02-25 dob/01-01-1990 s/F st/PENDING e/[email protected] bt/A+

Likely reason for failure is that the date should be in YYYY-MM-DD.

Command:
cluster 50.5 a/Serangoon d/DENGUE

Instead of saying that the cluster size is invalid, the error message says that the command format is invalid, which is untrue.
This is probably caused by insufficiently distinguishing the exception thrown by the input validator.

From the user guide, it is seen that the update visit feature wil not be included in the final stage of this project. However, there is not delete command that is specific to deleting a particular visit as well. As such, to update a visit (due to a typo or other reasons), the user has to use deleteinfo to delete the visit field. This can be problematic if there are a large number of visitations and only one visit record has to be updated.

As such, I do not think that this visit feature satisfies the minimally viable product requirement.

Command:
cluster 0 a/Serangoon d/DENGUE

The typo is given below.

When read S1234 is called, an unhandled exception is thrown.

This should be handled by showing an invalid input error message in the output box to help the user correct the input.
This is probably caused by not catching an exception thrown by the input validator as seen in the second screenshot.

You can replicate this behaviour by running the following commands in this specific order:

• find a/Geylang
• update S1234567A hp/91234567 e/[email protected]

This is likely caused by not checking for whether such a person exists in the display list after find has been run.
A simple fix could just be to catch errors like these and return an error message in the output.

Command:
cluster 9223372036854775807 a/Serangoon d/dengue

When given a really large cluster size, the program returns an error message that is not fitting of the situation as the issue lies not in the command format.
This is probably caused by a validation exception but it isn't sufficiently distinguished.

Command:
deleteinfo S1234567A asd/

The command format is correct but the issue lies in the fact that the field asd does not exist.

Instead of flagging it as an invalid command format, it would be better to flag it as a field not existing.

Consider standardising whether a full stop is needed when a line ends with code text and make sure to add full stops after each regular line of text.

Command:
deleteinfo S1234567A asd/

Typo found in deleteinfo error message for invalid command format.

Command:
delete T1234

The error message classifies this as an invalid command format when instead it is an invalid input.