C#: Generics and checking for null

When writing C#, in Visual Studio, using generics… have you ever tried checking for null? I have always found that a bit of a hassle.

Say we have this method which returns the subject if it is not null, and the result of a createNew() function if it is null.

public static T NewIfNull<T>(this T subject, Func<T> createNew)
{
    if (subject == null)
        return createNew();
    return subject;
}

Not claiming this is a very useful method, but it was the simplest thing I could come up with :P Anyways, in Visual Studio you will now probably have a blue (is blue here at least) squiggly line under the equality operator. It states you are doing a Possible compare of value type with ‘null’, which of course is reasonable and correct. We could just ignore it and move on… but we don’t really like squiggly lines, do we? I sure don’t… so lets get rid of it.

Faulty solution

ReSharper suggests that I use default(T) instead of null, like this:

public static T NewIfNull<T>(T subject, Func<T> createNew)
{
    if (subject == default(T))
        return createNew();
    return subject;
}

Now, this won’t do at all. First of all, we don’t really want to check for default(T), we want to check for null. And second of all, we now have a long red squiggly line under the whole equality statement! It says that it Cannot apply operator ‘==’ to operands of type ‘T’ and ‘T’. That messages doesn’t really make much sense to me, to be honest, but I trust that it is true. Either way, we have to get rid of it.

Good solution

ReferenceEquals to the rescue! We can use that method, instead of the equality operator, and compare with null like we intended! :D

public static T NewIfNull<T>(T subject, Func<T> createNew)
{
    if (ReferenceEquals(subject, null))
        return createNew();
    return subject;
}

That is kind of ugly though… And it is so much longer to type. And, most importantly, it kind of makes the code a bit unreadable… At least if you have a bunch of things you have to check for null, like I did today.

But fear not! Today I came up with a tiny, but brilliant extension method which makes things a lot better:

public static bool IsNull<T>(this T subject)
{
    return ReferenceEquals(subject, null);
}

public static T NewIfNull<T>(T subject, Func<T> createNew)
{
    if (subject.IsNull())
        return createNew();
    return subject;
}

Doesn’t that just look a lot cleaner? I think so :D

And yes, I know this isn’t really a big issue. And I realize you have probably all come up with something similar already. Yes, I am slow :P But hey, I figured it might be worth sharing this anyways, just in case you hadn’t thought about it before. I sure hadn’t! And I really do think that tiny snippet of code made a huge difference in code readability. And we all want that, don’t we? Yes, yes we do…

  • alh84001

    I just stumbled upon this and I’m glad I’m not the only one annoyed :). Thanks for the elegant solution too.

  • Ari

    Found it through Google! Thanks for the solution!

    • http://www.geekality.net Torleif

      You’re welcome! Glad it helped :)

  • JaiderNet

    One more thing, Instead of using `Func createNew` may you declare “… `where T: new()`, so you can use: `new T()`

    • http://www.geekality.net/ Torleif Berger

      You don’t always want to use a default constructor though, but yes, if you knew that would be the case you could simplify it in this case. Good point :)