Have You Checked For Null Lately?

09Sep08

Here’s a trick question for the developers out there: What’s wrong with this code?

    public class SomeClass
    {
        public string GiveMeAnObject(object someObject)
        {
            return someObject.ToString();
        }
    }

The title of this post gives it away, but technically there’s absolutely nothing wrong.  It compiles just fine.  And it runs just fine… as long as it’s given what it’s expecting, in this case a valid object.  The problem is that there is no guarantee it will always, or really ever, get what it expects since it’s public and therefore anyone can invoke it.

What’s wrong is that there is no guard clause to ensure that “someObject” is valid before we attempt to use it.  Without validating our parameters, we can never be sure they’re okay.

Consider the same code with the added security of a guard clause:

    public class SomeClass
    {
        public string GiveMeAnObject(object someObject)
        {
            if (someObject == null)
            {
                throw new ArgumentNullException("someObject", "Bleh! That was null!");
            }
 
            return someObject.ToString();
        }
    }

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Guard clauses and parameter validation are not new by any stretch, but they are still very relevant.  We see this type of code all the time, or at least bump into it whenever we see a System.NullReferenceException thrown in our application.  And, unfortunately, users will see this from time to time as well.  On one project I was on long ago, we would see so much code that failed to handle invalid parameters that it became our ongoing phrase…

Me: Say, I tried running our app this morning and it just threw an unhandled exception…

Teammate: Hmm… did you check for null?

Me: Aha!  Nope, no parameter validation on this one method here…! Thanks!

A few hours later…

Me: Say, I have this problem with this class I’m writing…

Teammate: Did you check for null?

Me: But you don’t even know what my problem is yet…

Teammate: But, did you check for null?

Me: No.. but…

Teammate: I really think you should check for null first.

* Not quite as catchy as “ninjas on fire”, but it worked for us.

Remembering to “check for null” is part of the defensive programming methodology that strives, among other things, to keep your code running no matter what happens.  And while users may not always, at least consciously, appreciate how often your app has not crashed on them, they definitely will remember the next time it goes belly-up.  And if they get some cryptic “unhandled exception” dialog (if it’s an executable) or YSOD (if it’s a website) while your app makes its last gasp, what that tells them is that something bad just happened and no one coded for it.  It can be disheartening, even scary, and serves to only diminish their trust in what you’ve built.  Keeping your code robust is one of those practices that might feel like a bit more work up front, but pays dividends later on.

And in case you’re wondering… yes, I too have forgotten to “check for null” before… so this post is just as much for me as anyone else.

Advertisements


%d bloggers like this: