为什么使用 EventArgs.Empty 而不是 null？答案

【问题标题】：Why use EventArgs.Empty instead of null?为什么使用 EventArgs.Empty 而不是 null？
【发布时间】：2018-12-03 20:36:26
【问题描述】：

我记得在多个场合和多个地点读到，当触发典型事件时：

protected virtual OnSomethingHappened()
{
    this.SomethingHappened(this, EventArgs.Empty);
}

如果没有有趣的事件参数，e 应该是 EventArgs.Empty，而不是 null。

我遵循了我的代码中的指导，但我意识到我不清楚为什么这是首选技术。为什么规定的合同更喜欢 EventArgs.Empty 而不是 null？

【问题讨论】：

【解决方案1】：

我相信 NOT NULL 背后的原因是，当作为参数传递时，该方法不需要潜在地处理空引用异常。

如果您传递 null，并且该方法尝试对 e 执行某些操作，它将获得 null 引用异常，而使用 EventArgs.Empty 则不会。

【讨论】：

在什么情况下你会在自己的代码中使用类似的技术？
如果一种方法可能会传递事件信息而另一种可能不会。无论如何，我仍然可以调用 e.ToString()，但一个可能会传递自定义类型，另一个传递 EventArgs.Empty
Greg，这里的重点是事件处理程序不是您的代码。您在这里需要安全第一，因为您正在定义和引发事件，而其他人将编写事件处理程序。
在事件周围有约定和规范，如果不能保证的话。一个是 EventArgs 应该永远为 null 并且处理程序不应该检查它。

【解决方案2】：

EventArgs.Empty 是Null object pattern 的一个实例。

基本上，有一个表示“无值”的对象，以避免在使用时检查 null。

【讨论】：

【解决方案3】：

我相信EventArgs.Empty 用于维护通过事件传递参数的约定，即使不需要任何参数。

Mitchel Sellers 在我的帖子中途发布了我的另一半理由：如果方法尝试使用该参数执行某些操作（除了检查它是否为空），它会防止空引用异常。

EventArgs.Empty 基本上完成了全局定义的事件参数的工作，没有额外的信息。

为了给出一个维护约定的类似示例，我们的团队使用string.Empty 来初始化一个字符串，因为否则不同的编码人员可能会使用newString = ""; or newString = " "; or newString = null;，所有这些都可能针对不同的检查条件产生不同的结果。

使用EventArgs.Empty 与new EventArgs() 的一个（有点迂腐的）原因是前者不会初始化新的EventArgs，从而节省了少量内存。

【讨论】：

【解决方案4】：

如果您正在使用具有EventHandler 签名的通用方法，该签名从任何事件处理程序中调用并同时传递object sender 和EventArgs e em>，它可以调用e.ToString()，例如，用于记录事件，而不用担心空指针异常。

【讨论】：

【解决方案5】：

我长时间使用“new EventArgs()”而不是“EventArgs.Empty”...我认为重要的是传递不会导致 Null 异常的东西。

【讨论】：

EventArgs.Empty 不为空，它是一个使用“new EventArgs()”初始化的静态变量。这意味着您最终不会浪费资源来初始化没有变化值的有效占位符对象。
如果 EventArgs 中没有有意义的数据，就不要实例化一个。 EventArgs.Empty 将完成这项工作，而无需创建一个只会被垃圾回收的无用对象。
我同意。使用 new EventArgs() 会使下一个出现的程序员的意图不太清楚，而且有点浪费。

【解决方案6】：

来自 Albahari 书："in order to avoid unnecessarily instantiating an instance of EventArgs."

【讨论】：