Parameter Verification for RepoConfiguration and CliArguments

[georgetayqy]

What feature(s) would you like to see in RepoSense

Previously, due to the constructors used in RepoConfiguration and CliArguments, only legal combinations of parameters were permitted in the construction of RepoConfiguration and CliArguments objects.

However, with the Builder pattern, this restriction in parameter combination is lifted, and hence there is a need to validate if the combination of provided parameters is legal.

Is the feature request related to a problem?

This issue is related to issues #2076, #2117 and #2119 and PR #2078.

If possible, describe the solution

We should first ascertain the legal parameter combinations for both RepoConfiguration and CliArguments, before implementing a method such as validate() to check if the provided parameters follow some established legal combination of parameters, before the Builder object builds the RepoConfiguration or CliArguments object.

If applicable, describe alternatives you've considered

One alternative we could consider would be providing documentation on what parameter combinations are valid, and explicitly warning users that deviations from these combinations may result in errors. This puts the burden of correctness on the user, and it assumes that the users are knowledgeable enough to know what combinations of parameters they would require to get their work done.

Alternatively, we could ascertain that certain mandatory parameters that the user is required to fill in are indeed filled in, and leverage the existing default values currently in use to ensure that other required parameters, if omitted, have a default value to fall back on if necessary.

Additional context

N/A

[logical-1985516]

Hi @asdfghjkxd, may I try this issue? I think that a combination of the alternatives would be the best approach, although it requires more effort.

[georgetayqy]

Hi @logical-1985516, go for it!

I agree that some combination of the alternative solutions would result in the best solution to this problem, albeit requiring more work!