在 C# 8 中，如何检测不可能的空值检查？

Question

我已经开始在 C# 8 中使用可为空的引用类型。到目前为止，除了一件小事之外，我很喜欢这种改进。

我正在迁移一个旧代码库，其中包含大量冗余或无法访问的代码，例如：

void Blah(SomeClass a) {
  if (a == null) {
    // this should be unreachable, since a is not nullable
  }
}

很遗憾，我没有看到任何可以为我标记此代码的警告设置！这是微软的疏忽，还是我遗漏了什么？

我也使用 ReSharper，但它的警告设置似乎也没有捕捉到这一点。有没有其他人找到解决这个问题的方法？

编辑：我知道从技术上讲这仍然是可以实现的，因为可空性检查不是防弹的。这不是重点。在这种情况下，我将参数声明为不可为空，检查它是否为空通常是错误的。在极少数情况下 null 作为不可为 null 的类型传入，我更愿意查看 NullReferenceException 并追踪错误传入 null 的违规代码。

Answer 1

值得注意的是，可空性检查不仅不是防弹的，而且虽然它们旨在阻止调用者发送 null 引用，但它们对防止 它。向此方法发送null 的代码仍然可以编译，并且参数值本身没有任何运行时验证。

如果您确定所有调用者都将使用 C# 8 的可空性上下文——例如，这是一个 internal 方法——并且你是 真的很努力地解决了来自 Roslyn 的静态流分析的所有警告（例如，您已将构建服务器配置为将它们视为错误），那么您是正确的，这些空检查是多余的。

然而，正如 the migration guide 中所述，任何不使用 C# 可空性上下文的外部代码都将完全忽略这一点：

新语法不提供运行时检查。外部代码可能会绕过编译器的流分析。

鉴于此，通常认为最佳做法是继续在任何 public 或 protected 成员中提供保护子句和其他可空性检查。

事实上，如果你使用微软的 Code Analysis 包——我会推荐它——它会警告你在这种情况下使用保护子句。他们考虑在 C# 8 的可空性上下文中删除此代码，但 decided to maintain it 由于上述问题。

当您从代码分析中收到这些警告时，您可以将代码包装在一个空检查中，就像您在此处所做的那样。但是你可以也抛出异常。事实上，您可以再抛出一个NullReferenceException——尽管绝对不推荐这样做。在这种情况下，您应该改为抛出ArgumentNullException，并将参数名称传递给构造函数：

void Blah(SomeClass a) {
  if (a == null) {
    throw new ArgumentNullException(nameof(a));
  }
  …
}

这比在源头抛出NullReferenceException 更可取，因为它向调用者传达他们可以通过显式命名传递的确切参数（在这种情况下）来避免这种情况作为null。这比仅仅获得NullReferenceException 以及可能对发生异常的内部代码的引用更有用。

至关重要的是，此异常并不是为了帮助你调试你的代码——这就是代码分析正在为你做的事情。相反，它表明您已经确定了空值的潜在取消引用，并且您在源头解决了它。

注意：这些保护子句会给你的代码增加很多混乱。我的偏好是创建一个可重用的内部实用程序，通过一行来处理这个问题。或者，上述代码的单行简写是：

void Blah(SomeClass a) {
  _ = a?? throw new ArgumentNullException(nameof(a));
}

这是回答原始问题的一种非常迂回的方式，即如何检测是否存在因 C# 的不可为空引用类型而不必要的空值检查。

简短的回答是你不能；此时，Roselyn 的静态流分析专注于识别解除引用空对象的可能性，而不是检测潜在的无关检查。

不过，如上所述，长答案是您不应该；在 Microsoft adds runtime validation 或强制为空上下文之前，这些空检查继续提供价值。