Take the 2-minute tour ×

Well, a few months ago I asked a similar question about C and C++, but I've been paying more attention to C# lately due to the whole "Windows Phone" thing.

So, in C#, should one bother to check against NULL at method boundaries? I think this is different than in C and C++, because in C# one generally can determine whether a given reference is valid -- the compiler will prevent one from passing uninitialized references anywhere, and therefore the only remaining possible mistake is for it to be null. Furthermore, there's a specific exception defined inside the .NET Framework for these things, the ArgumentNullException, which seems to codify what programmers think they should be getting when an invalid null was passed.

My personal opinion is once again that a caller doing this is broken, and that said caller should have NREs thrown at them until the end of days. However, I'm much less sure about this than I am in native code land -- C# has quite a different programming style in places compared to either C or C++ in this regard.

So... should you check for null parameters in C# methods?

share|improve this question
That arguments tag seems to carry two meanings here, eh? :P –  BoltClock May 7 '11 at 4:07
@BoltClock: Lol -- I hope not. I don't mean to start flamewars on these things, but they seem to happen anyway. –  Billy ONeal May 7 '11 at 4:07
Human nature :/ –  BoltClock May 7 '11 at 4:39
@downvoter: Do you have a specific problem with this question? –  Billy ONeal Jun 23 '11 at 22:41

4 Answers 4

up vote 9 down vote accepted

Yes, check for them. Preferably use Code Contracts to tell the caller that you require non-null parameters

void Foo(Bar bar) {
    Contract.Requires(bar != null);

This is particularly advantageous since the client can see exactly what is required of parameters.

If you can't use Code Contracts, use a guard clause

void Foo(Bar bar) {
    Guard.Against<ArgumentNullException>(bar == null);

Fail fast.

share|improve this answer
will Contract.Requires(bar != null); flag Foo(null); at compile time which I doubt it will in which case what is the advantage of using something like this compared to a simple null check with if? –  Bala R May 7 '11 at 4:17
Where do Contract/Guard come from? I'm not familiar with those bits. :/ Does this apply to publicly exposed methods, or intra component methods as well? –  Billy ONeal May 7 '11 at 4:37
@Billy ONeal: That looks like NCommon: github.com/riteshrao/ncommon –  BrokenGlass May 7 '11 at 4:48
@Bala R: You can do static checking, and it becomes part of the documentation. –  Jason May 7 '11 at 5:06
The Contracts/Guard part distracts a little from the answer. How you check depends on several factors. I like Contracts but it won't be acceptable everywhere (yet). –  Henk Holterman May 7 '11 at 7:50

I think it's better to throw an ArgumentNullException (or use a contract as Jason suggests) if your method doesn't want a particular parameter to be null. It's a much better indicator by the contract to the client not to pass null in the first place when calling your method.

Null-checking is then the client's responsibility which makes for more maintainable code on both sides (often a win-win situation)... at least that's what I feel.

share|improve this answer
Do you think this is a must for exposed library methods only, or internally as well? –  Billy ONeal May 7 '11 at 4:38
@Billy: Only do this for exposed library methods. Only methods that are marked as public should do parameter validation of any type. It's an unnecessary expense for internal and private methods, that's one of the reasons to have methods that aren't part of the interface in the first place. –  Cody Gray May 7 '11 at 7:59
@Cody: What if the class itself is not exposed? E.g. the class is internal. –  Billy ONeal May 9 '11 at 23:24
@Billy: That's really the same thing. The access level of the class mediates the access level of its individual members. If the class can't be used outside of the library, it's not part of it's public interface. You might want to implement parameter validation simply for convenience or thoroughness inside of the library, but it's not strictly necessary, as the internal code can be strictly vetted. The only problem is for classes that are going to be exposed externally, used in situations where the callers can't be vetted and tested extensively. –  Cody Gray May 10 '11 at 7:57

It is a good practice to validate all the parameters at least in public methods. This helps to locate bugs faster and also helps while reading the code, as it describes method's contract.

We implemented a static class AssertUtilities that has a bunch of method for parameters and state validation. I believe some people call such classes Guard.

For example:

    public static void ArgumentNotNull(object argument, string argumentName)
        if (argument == null)
            throw new ArgumentNullException(argumentName);

    public static void ArgumentInRange(decimal argument, decimal minValue, decimal maxValue, string argumentName)
        if (argument < minValue || argument > maxValue)
            throw new ArgumentOutOfRangeException(
                FormatUtilities.Format("Argument out of range: {0}. Must be between {1} and {2}.", argument, minValue, maxValue));

    public static void ArgumentState(bool expression, string argumentName, string formatText, params object[] args)
        if (!expression)
            throw new ArgumentException(FormatUtilities.Format(formatText, args), argumentName);

    public static void ArgumentHasText(string argument, string argumentName)
        ArgumentNotNull(argument, argumentName);
        ArgumentState(argument.Length > 0, argumentName, "Argument cannot be an empty string.");
share|improve this answer


Yes, unless of course when null is permitted.

A better perspective: You should always check for valid parameter values. Sometimes a reference is allowed to be null, sometimes an int must be >= 0 or a string may not be NullOrWhiteSpace.

So it is a good practice to start every method with a parameter validation block.

From there on there are a few choices. Validation on internal/private methods is usually considered less critical, and for performance reasons it can be made conditional (or even left out).

Validation at a boundary is usually left on in Release builds. There is very little reason to ever turn it off.

Most projects will use some helper classes for validation, to minimize repetitive coding inside the methods. A very good but not yet very popular toolkit is the built-in System.Diagnostics.Contracts class. The Code-Contracts tools have many settings concerning parameter validation.

share|improve this answer
See, I strongly disagree for the "check for valid parameters" bit -- in general case that is not possible or practical, even in environments as restricted as the CLR. –  Billy ONeal May 9 '11 at 23:22

Your Answer


