Parameter Validation Best Practices

Question

Imagine you have an application which is some kind of front-end to all your business logic. This front-end has a lot of DLLs upon which it depends, and the methods in those DLLs may call each other repeatedly upon a single execution of a given method in the front-end. If the users of your application do not directly access those DLLs, should you...

1) Risk a (small) performance hit and validate parameters in each of those methods, even if you can end up validating the same parameters some 5 times; or

2) Risk unexpected behaviour and assume that, as you validate input parameters, all the other possible parameters passed to and from your internal code are valid (for example, neither null nor empty)?

Edit: Just to give an example, suppose you have a Regex RegexA and a method

internal bool Matches(string expression)
{
    return RegexA.IsMatch(expression);
}

IsMatch will throw an exception on a null parameter, but not on the empty string. If you know beforehand that an empty string will never be a match to that Regex, should you use if (String.IsNullOrEmpty(expression)) before, even knowing that it may be validated for nullity inside the IsMatch framework method? In this case you are clearly repeating a validation, but is it better to repeat it or to risk?

Answer 1

Usually parameter checks are very cheap, even if called thousands of times. For example test if a value is null, a string or Collection is emtpy a number is in a given range.

But beware that checks may be expensive, so think twice: Evaluating a regex on a large string, checking if a file exists, checking that all elements in a collection meets a certain criteria.

I would also only recommend checking only in public or protected methods. Note that all public methods with unchecked parameters are potential risks!

EDIT/another thought: If a method does not use the parameters but is just passing it to another method then you may also omit the checking. Only the method which is actually using these parameters for itself should do the checking.

This is because if the requirements of the parameters change you need to change the validations in multiple places, risking inconsistency.

Answer 2

As an author of a library, you cannot assume that the consumers have done proper validation of inputs, so you as a library author would want to ensure the arguments are valid before going to work with them.

As a consumer of a library, if you know what inputs are going to cause the library to fail, why would you pass those inputs to that library? Validate against them so that you can perhaps prompt your user for better inputs or otherwise cancel whatever process you are in.

The fact that you might be the author of both the library and the consumer is not particularly relevant, in my opinion, as this relationship may very well change.