Good way to handle error messages of validation methods

Question

I've written an licensing system, which checks different aspects of a license (e.g. Start Date, End Date, System Restrictions etc.). In example I have an restriction in a license, which says you can't create more than 5 user accounts. I have a Method (e.g. bool NumberOfUsersIsCoveredByLicense), which calls an common method (e.g. bool IsValidLicense). IsValidLicense would check if the license file is manipulated, expired etc.

The problem right now is the erroroutput. As you can see I have methods with a bool return value, so I know there was a license violation, but I don't know which part of the license check failed. So I'm thinking about, how to return a value, which describes which part of the license was violated. The easiest way would be to return a string value, I would do something like

var licenseValidationResult = NumberOfUsersIsCoveredByLicense(4)
if(licenseValidationResult.Equals(String.Empty))
{
    //Success
}
else
{
    ErrorMessage = GetErrorMessageByErrorCode(licenseValidationResult);
}

So if the license is valid I would return a empty string, if it's invalid it would return the errorcode(s) in a form like error1;error2;error3.. I'm actually not sure, if this is a good soulution. Another possibility would be a enumeration, something like this:

[Flags]
public enum LicenseErrorCodes
{
    None = 0x00,
    LicenseExpired = 0x01,
    LicenseManipulated = 0x02,
    MaxNumberOfUsersReached = 0x04,
    [...]
}

But again, I'm not sure if this would be a nice solution. Is there any "common way"/best practice to solve such a problem?

Answer 1

Using an enumeration is fine if you want to restrict the possible states of invalidation. That will allow your UI etc to handle each possible state. If you have many, variant, states from your validation system then I'd recommend just creating a validation class that holds the relevant information and returning that from your validatior e.g.:

static IValidationInfo Validate(ILicense someLic)
{
    // Implementation
}

interface IValidationInfo
{
    IEnumerable<LicenseErrorCodes> KnownErrors { get; }
    IEnumerable<string> WierdErrors { get; }
}

Creating classes is a lightweight process so the performance considerations compared to something like the 'out' solution suggested are going to be minimal.

Edit: Additionally, I'd also recommend against using exceptions for validators. At least to me, a validator should be designed to take input and validate it. Let consumers deal with any invalid data errors it spits out without having to do so in a try{} catch{} block. Exceptions should only really be used for unpredictable/external issues that can't directly be handled by consumers e.g. File access issues or COM invalidation.

Answer 2

If the license violation is considered fail or error to you, then it's probably reasonable to throw the exception at the point where it fails.

So, define your InvalidLicenseException ..

Answer 3

How about using out parameters. So you can still return a boolean for success or failure, but also add an out messageString parameter to the isValidLicence method. Or define a Licence Violation class and use that.