[ACCEPTED]-Parameter Validation Best Practices-parameter-passing

Unless the validation of the parameter is 30 going to be expensive, I would go with #1. Fail-fast 29 behavior lets you catch bugs in a fraction 28 of the time, which will save you a lot more 27 time than it takes to write a few guard 26 statements at the beginning of each method.

One 25 technology you may be interested to help 24 with this is .NET's Code Contracts, which 23 allow you to create quasi-compile-time checks 22 to ensure that nobody calls a method without 21 ensuring that the inputs match the expected 20 patterns.

I personally tried using Code Contracts, and 19 found that there was a little too much overhead 18 for my needs. However, I appreciated the 17 syntax, so I made a class to help with these 16 guard statements, but which only works at 15 run-time. It works like this:

public void ChangeUserName(int userId, string name)
{
    Require.ThatArgument(userId > 0);
    Require.ThatArgument(!string.IsNullOrWhitespace(name,
        () => "Usernames must be non-empty strings");
    var user = GetUser(userId);
    Require.That(user != null, 
        () => new UserDoesNotExistException("No user exists with ID " + userId));
    user.Name = name;
    ...
}

And one final 14 technology that helps a lot for these checks 13 is Resharper's Annotations. For example, consider 12 the following method:

[CanBeNull]
public User GetUser(int userId)
{
    var user =  ... // Get the user from the db
    return user;
}

By telling Resharper 11 that the method might return a null value, it 10 will know to warn you if you haven't done 9 a null check on user before trying to access 8 user.Name. Another annotation is available to tell 7 Resharper that Require.That(user != null) constitutes a null check. You 6 could also re-write your method like this:

[NotNull]
public User GetUser(int userId)
{
    Require.ThatArgument(userId > 0);
    var user =  ... // Get the user from the db
    Require.That(user != null)
    return user;
}

By 5 marking this method as NotNull, Resharper 4 can automatically tell you that user != null will always 3 resolve to true so you don't have to check for 2 it. There are all kinds of fun stuff you 1 can do to make validation easier.

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

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

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

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

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

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

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

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

Very interesting topic :)

in general you 9 should implement a "validation facade" lower 8 than the user interface and at the lowest 7 possible level commonly accessed by user 6 interface and external services.

you can 5 check for null and validate input also in 4 the UI just to avoid a useless round-trip 3 to the server, client side validation is 2 a good practice, still you cannot trust 1 the caller to only pass you valid values.

You may get mixed opinions, but in my view..it 3 is best to do validation in both the layers. In 2 the front and the business logic (dlls as 1 you call it)