Throwing exception vs checking null, for a null argument

What factors dictate throwing an 开发者_StackOverflowexception if argument is null (eg if (a is null) throw new ArgumentNullException() ), as opposed to checking the argument if it is null beforehand.

I don't see why the exception should be thrown rather than checking for null in the first place? What benefit is there in the throw exception approach?

This is for C#/.NET

Thanks

Generally you throw ArgumentNullException when an argument gets passed who's value is null but should "never" be null. Its a specific ArgumentException for dealing with nulls.

Oftentimes, if you're aware you're going to get null values as args, you check for null and plan the rest of your method accordingly -- often creating records if none exist, or doing a different subroutine than would've ran if a valid argument was present. In this case, I typically don't use ArgumentNullException because I plan on null being a valid input.

I only use ArgumentNullException when I'm positive something shouldn't be null when it gets there, and I want to make note of an argument thats defined as "invalid".

Your method can do one of three things when an argument is null. It can throw an exception, it can return without doing anything, or it can make assumptions and attempt to continue. I'm assuming you are trying to choose between the first two options.

Since the calling method can always check the arguments prior to calling your method it can prevent invalid values from being passed. This is true regardless of how your method handles invalid values.

When your method is called with invalid arguments it should notify the caller that processing did not continue. You can notify it by throwing an exception or returning an error value. If you check for null and don't return an error value the calling method will assume your method processed with no errors.

How do you want the calling method to handle the case where your method does not process? If passing null is a normal occurrence and should be easily handled by the calling method returning an error on a null argument is acceptable. In this case the calling method either checks the arguments prior or the return value after the choice is up to whoever writes the calling method.

If passing a null is very rare then throw an exception. The calling method can prevent the exception by checking arguments before calling your method just like above. By throwing an exception the call stack can be unwound without having to add lots of code.

Summary:
If an argument set to null is routine and the calling method should be written to handle your function returning without doing anything just return an error value. If a null argument is rare and the calling method can't be expected to handle your method doing nothing throw an exception so the call stack is unwound.

Don't ever write code that checks for a null argument and then does nothing. Hiding bugs in the client code is quite wrong, you want to be as helpful as possible when your API doesn't get used properly.

ArgumentNullException is very helpful.

As a method writer, you must decide whether you can reasonably infer what the caller may have meant by null. If you can, take action. If you cannot, throw ArgumentNullException to inform the caller they gave you a value you cannot use.

It's defensive programming - die as early and as informatively as possible, instead of trying to limp along with partially valid state, which turns into much more subtle (and harder to fix) bugs.

This is about deciding what the contract for your method is. If you want the contract to be that callers must not pass in a null, you must throw an exception if you get one. Don't trust the caller to never make that mistake! OTOH, if you want the contract to be not quite so restrictive in that argument (whatever that means; either doing nothing gracefully or some other kind of behavior) then an exception is obviously wrong.

Whatever you do, document it. Give the poor caller a chance to get it right before throwing things at your method...