The API Design Guidelines encourage developers to check all their arguments and thereby avoid throwing a NullReferenceException. If an argument is null and the contract of the method forbids null arguments an ArgumentNullException should be thrown.
I get pushback on this periodically from developers that feel like the extra checks they are forced to implement are redundant. Consider the following code:
public void PrintValue(object o)
//Insert possibly deep callstackâ€
If you pass an instance that happens to be null nothing will blow-up or AV the process… you will simply get a NullReferenceException. That is way better than the equivalent thing in Win32, so what is the problem? The problem is developer productivity. If I have been up all night working on a program and I hit a NullReferenceException from 10 levels deep into Microsoft code I am likely to assume the bug is in the platform rather than my code (Occam's razor not withstanding). Now a few more hours later and maybe a call to PSS and I will realize my mistake, but I will certainly not be amazingly happy with the platform.
Suppose the author of the PrintValue() method followed our design guidelines
if (o == null) throw new ArgumentNullException();
Now, in the exact same circumstance I get an ArgumentNullException that specifically tells me I passed a null value where it was not expected. I immediately know the error is in my code and I can quickly find and fix my bug. Although I may not be able to attribute it to exactly this instance, I am overall much more happy and productive on the platform.
What do you think? Is this kind of error checking helpful in the .NET Framework and WinFX?