这比 Null Coalesce 运算符好在哪里？

Question

我遇到了这个< /a> 今天的博客文章。

我来总结一下。博主评论这段代码，说它很难看。

// 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;

然后博主继续编写一个类，允许您用新的语法替换上面的代码。

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

Dis 类的代码如下。

 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;
      }
    }
  }

所以我的第一个问题是为什么包含 ?? 的原始代码必须替换为看起来该死的 ?: 代码。

我的第二个问题是为什么使用表达式树而不是空合并？我能想到的唯一原因是因为他们使用了延迟初始化，但这从帖子中并不清楚，从博文中的测试代码也不清楚。我也会在这里发布。

顺便说一句，有人知道如何创建固定大小的代码块窗口吗？或者这里更喜欢非滚动代码块？我在元博客中没有看到任何内容。

Answer 1

我看不出有任何理由在博客示例中使用表达式树，Func 就足够了。

我的建议是使用 Maybe* monad 实现，而不是该代码。参见示例。

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;
    }
}

你的代码变成：

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

[*] 这不是真正的 monad，而是它的一个非常简化的版本。

Answer 2

代码是博客更糟糕。方法名称 Dis.OrDat 很难看，并且没有描述该方法实际执行的操作。

使用 Expression 是多余的，可能只是：

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

他立即依次调用 Compile 和 Invoke，所以他实际上并没有对表达式树做任何事情。按原样传入 Func 是一样的，没有编译 Func 的开销。

但更糟糕的是，代码使用流量控制异常，这总是不好的：人.Address 属性似乎是可选的，因此它为空并不是“异常”，因此使用它的代码不应引发异常。上面的 catch 无法区分 person.Address == null 和 Address 属性 getter 的实现在内部被破坏，导致 >NullReferenceException 被抛出。它只是将它们全部吞噬。

因此，总的来说，我很乐意忽略这篇博文。

Answer 3

为了保护这段代码：

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

不抛出 NullReferenceException

我会简单地使用：

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

而不是博客这个或那个（Dis.OrDat），

Answer 4

第一行代码（ var line1 = person.Address.Lines.Line1 ?? string.Empty ）的问题是，如果 person、Address 或 Lines 为 null，则会抛出错误。空合并运算符仅作用于整个表达式的结果。

这是一个相当优雅的解决方案，但在我开始在我的代码中使用它之前，我想检查一下表达式树的性能如何（但这只是因为我过去过度使用反射，然后才知道它是什么狗） ）

Answer 5

对于你的第一个问题，有问题的代码：

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

如果 person、Address 或 Lines 为 将抛出 NullReferenceException >空。使用三元 if 语句的替换代码可以防止出现这种情况。 null 合并运算符仅对 Line1 属性进行操作，因此它无法防止表达式的其余部分为 null。

对于第二个问题，使用表达式树的原因可能是为了“简化”确保可以评估整个表达式所需的代码。虽然代码可以工作，但我认为它引入了一层并不真正必要或不需要的复杂性和开销。

Answer 6

对于那些查看此条目但使用 C# 6.0（或更高版本）的人，代码现在可以使用空传播，并编写如下：

var line1 = person?.Address?.Lines? .Line1 ?? “不适用”；