How is this better than the Null Coalesce operator?

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 anythin开发者_如何学运维g in the Meta blog.

---

I do not see any reason to use expression trees in blogged sample, Func is enough there.

My suggestion is using Maybe* monad iplementation, instead of that code. See example.

public static class Maybe
{
    public static TResult With<T, TResult>(this T self, Func<T, TResult> func) where T : class
    {
        if (self != null)
            return func(self);
        return default(TResult);
    }

    public static TResult Return<T, TResult>(this T self, Func<T, TResult> func, TResult result) where T : class
    {
        if (self != null)
            return func(self);
        return result;
    }
}

And your code becomes:

var line2 = person
   .With(p => p.Address)
   .With(a => a.Lines)
   .Return(l => l.Line2, "n/a");

[*] This is not actual monad, but a very simplified version of it.

---

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.

---

To protect this code:

var line1 = person.Address.Lines.Line1 ?? string.Empty;

from throwing NullReferenceException

I would simply use:

var line1 = string.Empty;
if ((person.Address != null) && (person.Address.Lines != null))
   line1 = person.Address.Lines.Line1 ?? string.Empty;

rather than the Bloggers this or that (Dis.OrDat),

---

the problem with the first line of code ( var line1 = person.Address.Lines.Line1 ?? string.Empty ) is that it will throw an error if person, Address or Lines is null. The null coalescing operator is only working on the result of the entire expression.

It's a fairly elegant solution but I'd want to check what the performance of expression trees was like before I started sprinkling this through my code (but only because I got bit by overuse of reflection in the past before I knew what a dog it was)

---

For your first question, the code in question:

var line1 = person.Address.Lines.Line1 ?? string.Empty;

will throw a NullReferenceException if person, Address, or Lines is null. The replacement code using the ternary if statements protects against that case. The null coalescing operator will only operate on the Line1 property, so it can't protect against the rest of the expression being null.

For your second question, the reason for using the expression tree is probably to "simplify" the code required to ensure the entire expression can be evauluated. While the code would work, I think it introduces a layer of complexity and overhead that isn't really necessary or needed.

---

For those looking at this entry but using C# 6.0 (or higher), the code can now use Null Propagation, and be written as follows:

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