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â€

            Console.WriteLine(o.ToString());

        }

 

 

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

 

        public void PrintValue(object o)

        {

            if (o == null) throw new ArgumentNullException();

            //Insert possibly deep callstackâ€

            Console.WriteLine(o.ToString());

        }

 

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?