How is this better than the Null Coalesce operator?

Question

I ran into this blog post today.

I'll summarize. The blogger is commenting on this code and saying it was ugly.

// var line1 = person.Address.Lines.Line1 ?? string.Empty;
// throws NullReferenceException: 
//    {"Object reference not set to an instance of an object."}

// The ugly alternative

var line1 = person.Address == null
    ? "n/a"
    : person.Address.Lines == null
    ? "n/a"
    : person.Address.Lines.Line1;

The blogger then goes on to write a class that allows you to replace above code with a new syntax.

var line2 = Dis.OrDat<string>(() => person.Address.Lines.Line2, "n/a");

The code for the Class Dis is as follows.

 public static class Dis
  {
    public static T OrDat<T>(Expression<Func<T>> expr, T dat)
    {
      try
      {
        var func = expr.Compile();
        var result = func.Invoke();
        return result ?? dat; //now we can coalesce
      }
      catch (NullReferenceException)
      {
        return dat;
      }
    }
  }

So the first question I have is why would the original code containing ?? have to be replaced with the accursed looking ?: code.

My second question is why use the expression tree over the Null Coalesce? The only reason I can think of it is because they are using lazy initialization, but that is not clear from the post, nor is it clear from the test code, which is in the blogpost. I'll post that here as well.

BTW, anyone know how to create a fixed sized code block window? Or is a non scrolling codeblock prefered here? I didn't see anything in the Meta blog.

Answer 1

The code is the blog is worse. A method name Dis.OrDat is ugly, and doesn't describe what the method actually does.

The use of an Expression<T> is redundant, it could just be:

public static T OrDat<T>(Func<T> func, T dat)
{
  try
  {
    return func() ?? dat;
  }
  catch (NullReferenceException)
  {
    return dat;
  }
}

He calls Compile and Invoke one after another right away, so he doesn't actually do anything with the expression tree. Passing in the Func<T> as is would be the same, without the overhead of compiling the Func.

But worse, the code uses exceptions for flow control, which is always bad: the person.Address property appears to be optional, so it isn't "exceptional" for it to be null, so an exception shouldn't be thrown by code which uses it. The catch above can't distinguish between person.Address == null and the implementation of the Address property getter being broken internally causing an NullReferenceException to be thrown. It just swallows them all.

So, overall, I'd be happy to disregard the blog post.