为什么编译器至少不警告 this == null

Question

为什么 C# 编译器甚至不抱怨这段代码的警告？ ：

if (this == null)
{
   // ...
}

显然这个条件永远不会被满足。

Answer 1

这也与 C# 所做的（或没有做的）其他警告一致，例如：

if(true)
or 
if(1 == 1)

无论如何，这些警告也将始终具有相同的结果。

Answer 2

因为您可以覆盖operator == 对于这种情况返回 true。

public class Foo
{
    public void Test()
    {
        Console.WriteLine(this == null);
    }

    public static bool operator ==(Foo a, Foo b)
    {
        return true;
    }

    public static bool operator !=(Foo a, Foo b)
    {
        return true;
    }
}

运行 new Foo().Test() 将在控制台打印“True”。

这里的另一个问题是：为什么编译器不针对 ReferenceEquals(this, null) 发出警告？从上述链接的底部：

operator == 重载中的一个常见错误是使用 (a == b)、(a == null)、或 (b == null) 检查引用是否相等。相反，这会导致调用重载的运算符==，从而导致无限循环。使用 ReferenceEquals 或将类型转换为 Object，以避免循环。

这可能可以通过 @Aaronaught 的回复来回答。这也是为什么您应该执行 (object)x == null 或 ReferenceEquals(x, null)，而不是执行简单的 x == null code>，当您检查空引用时。当然，除非您确定 == 运算符没有重载。

Answer 3

哇...我想我错得可耻

我不同意。我觉得你说的还是有道理的。

编译器知道比较是否将进行到用户定义的比较运算符，并且编译器知道如果不是，则“this”永远不会为空。

事实上，编译器确实会跟踪给定表达式是否可以合法地为 null，以便对非虚拟方法调用实现较小的优化。如果您有一个非虚拟方法 M 并且您说 foo.M(); 那么编译器会将其生成为“使用接收者 foo 对 M 进行虚拟调用”。为什么？因为我们想在 foo 为 null 时抛出异常，并且虚拟调用总是对接收者进行 null 检查。非虚拟调用则不会；我们必须将其生成为“检查 foo 是否为 null，然后对 M 进行非虚拟调用”，这是更长、更慢、更烦人的代码。

现在，如果我们可以不进行空检查就可以逃脱，我们就会这样做。如果您说 this.M() 或 (new Foo()).M() 那么我们不会生成虚拟调用。我们生成非虚拟调用而不进行 null 检查，因为我们知道它不能为 null。

因此，编译器拥有关于与 null 的特定比较是否有时、总是或永远不会成功的出色数据。

那么问题是“如果编译器知道特定的比较永远不会成功，为什么不为其生成警告呢？”

答案是“有时我们这样做，有时我们不这样做”。

我们在这种情况下这样做：

int x = 123;
if (x == null) ...

在两个可为 null 的整数上定义了一个相等运算符。 x 可转换为可空 int。 null 可转换为可空 int。因此相等运算符是有效的，因此被使用，当然总是错误的。编译器会发出警告，指出该表达式始终为 false。

然而，由于我们在 C# 3 中意外引入的错误，此代码不会产生该警告：

Guid x = whatever;
if (x == null) ...

Same deal。可空 guid 相等运算符有效，但警告被抑制。我不确定我们是否修复了 C# 4 的这个错误。如果没有，希望我们能将其纳入服务包中。

至于“if (this == null)”我不知道为什么我们不对此发出警告。这看起来确实是一个很好的警告候选者。最可能的解释是遵循这个逻辑三段论：

• 警告是编译器功能，
• 编译器功能必须 (1) 考虑、(2) 设计、(3) 实现、(4) 测试、(5) 记录和 (6) 交付给在您可以利用该功能之前。
• 没有人为该功能完成这六项必要的工作中的任何一项；我们无法发布我们一开始从未想到的功能。
• 因此，没有这样的功能。

有无数的编译器特性是我们还没有想到的；我们没有实施其中任何一个。

此处不发出警告的另一个原因是，我们尝试对可能是意外键入的代码以及由于非明显原因几乎肯定是错误的代码发出警告 。 “this == null”不太可能是偶然输入的，尽管它几乎肯定是错误的，正如您在问题陈述中指出的那样，它显然是错误的。

与我们的“guid == null”相比——这很可能是偶然发生的，因为开发人员可能会意外地认为 Guid 是引用类型。在 C++ 中，指南通常通过引用传递，因此这是一个很容易犯的错误。该代码几乎肯定是错误的，但错误的方式并不明显。所以这是一个很好的警告候选者。 （这就是为什么不幸的是，由于我们引入了一个错误，这是 C# 2 中的警告，而不是 C# 3 中的警告。）

Answer 4

实际上，这种情况确实可以 满意，至少在 Visual Studio 2008 中。他们已在 VS 2010 中修复了此行为，但并非完全不可想象可能存在另一种方法来创建这种情况。

（tl;dr 版本 - 在 C# 3.5 中，从作为构造函数参数传递的匿名函数引用 this 是合法的，但如果您实际尝试使用它，您会发现 this 为 null。）

Answer 5

尽管下面的代码很糟糕，但它仍然是 C# 代码。如果调用 Bar，您将收到 InvalidOperationException 并显示消息 null。

public class Foo
{
    static Action squareIt;
    static Foo() {
        var method = new DynamicMethod(
                                       "TryItForReal",
                                       typeof(void),
                                       Type.EmptyTypes,
                                       typeof(Foo).Module);
        ILGenerator il = method.GetILGenerator();
        il.Emit(OpCodes.Ldnull);
        il.Emit(OpCodes.Call, typeof(Foo).GetMethod("tryit"));
        il.Emit(OpCodes.Ret);
        squareIt = (Action)method.CreateDelegate(typeof(Action));
    }

    public void tryit()
    {
        if (this == null) {
            throw new InvalidOperationException("Was null");
        }
    }

    public void Bar() {
        squareIt();
    }
}