Handle or not to handle null parameters with exceptions

Question

I remember reading some exception handling guidance that checking for null parameters was discouraged. The justification for this was, that if you left the code as is, an exception would be raised (NullReferenceExcpetion) when you attempted to use the parameter. The alternative is explicitly checking for null and throwing an ArgumentNullException.

This gives the same effect but you're right extra lines of code. You wouldn't ever write code to handle either exception and thus you'd really encounter these at runtime when testing and then fix the code to stop the exceptions from happening in the first place.

I'm not saying I agree with the guidance but it did make sense when I first read it and still makes sense now.

I generally check for null parameters on non-private methods only but leave private methods to throw a NullReferenceException.

Does anyone know if there is any definitive/de facto best guidance practice on this so I can update my approach if needed?

Answer 1

This gives the same effect but you're right extra lines of code

No it doesn't. Consider:

public void TransferMoney(Account from, Account to, decimal amount)
{
    from.Debit(amount);
    to.Credit(amount);
}

vs

public void TransferMoney(Account from, Account to, decimal amount)
{
    // Ideally do them separately
    if (from == null || to == null)
    {
        throw new ArgumentNullException();
    }

    from.Debit(amount);
    to.Credit(amount);
}

Both will fail with exceptions - but the first one will fail having caused a side-effect first. That's bad, and should be avoided where possible.

(Obviously in a real scenario this would presumably be transactional, and there would be no real harm done, but you take my point.)

Also, if one parameter is used as an argument for another method - or worse still, stored for later use - you can end up with the exception being thrown from a completely different place, in a way which may make it entirely non-obvious what the original problem was.

I generally check for null parameters on non-private methods only but leave private methods to throw a NullReferenceException.

That seems like a fairly reasonable policy. If a private/internal method is called from some hairy code and I'm concerned that I may have messed things up, I sometimes validate it even then.