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

Question

我记得在多次阅读以及多个地点看到过这样的说法：当触发典型事件时：

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

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

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

- Greg D

Answer 1

我认为 NOT NULL 的原因是，当它作为参数传递时，不希望方法需要处理潜在的空引用异常。

如果您传递 null，并且方法尝试对其进行操作，它将获得空引用异常；但如果使用 EventArgs.Empty，则不会有此问题。

- Mitchel Sellers

---

在您自己的代码中，您会在什么情况下使用类似的技术？ - Greg D

即使其中一种方法可能会传递事件信息而另一种则不会，我仍然可以调用 e.ToString() 方法，但是其中一种方法可能会传递自定义类型，而另一种则传递 EventArgs.Empty。 - Mitchel Sellers

这里的重点是事件处理程序不是你的代码。你需要优先考虑安全性，因为你正在定义和触发事件，而其他人将编写事件处理程序。 - Concrete Gannet

在事件中有一些惯例和规范，如果没有保证的话。其中一个是 EventArgs 绝对不应该为 null，而且处理程序也不应该检查它。 - Concrete Gannet

Answer 2

EventArgs.Empty 是 空对象模式 的一个实例。

基本上，它代表“无值”的对象，在使用时可以避免检查是否为null。

- Martin Konicek

Answer 3

我认为EventArgs.Empty用于保持传递事件参数的惯例，即使不需要任何参数。

Mitchel Sellers在我的帖子中间发布了另一半原因：它可以防止方法尝试对该参数执行某些操作（而不仅仅是检查它是否为空）导致空引用异常。

EventArgs.Empty基本上执行全局定义的事件参数的工作，没有其他信息。

举个类似的例子来保持惯例，我们的团队使用string.Empty来初始化字符串，否则不同的编码人员可能会使用newString = "";或 newString = " ";或 newString = null;，所有这些都可能为不同的检查条件产生不同的结果。

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

- ForCripeSake

---

“轻微的内存量”可能对于像MouseMove事件这样被多次触发的事件来说是非常重要的。 - Concrete Gannet

EventArgs.Empty返回一个对新的EventArgs实例的引用，那么内存节省从哪里来呢？ - user6338533

Answer 4

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

- marxidad

Answer 5

来自Albahari书籍："为了避免不必要地实例化EventArgs的实例。"

- Bobak_KS

---

null 无法创建 EventArgs 的实例。 - Greg D

Answer 6

我曾经使用了很长时间的"new EventArgs()"而不是"EventArgs.Empty"...... 我认为重要的是传递一些不会引起空异常的东西。

- Daok

---

EventArgs.Empty 不是 null，它是一个静态变量，初始化为 "new EventArgs()"。这意味着您不会浪费资源来初始化实际上是没有变化值的占位符对象。 - ICR

如果 EventArgs 中没有有意义的数据，不要实例化一个。使用 EventArgs.Empty 就能完成任务，而无需创建一个无用的对象，最终该对象只会被垃圾回收。 - Concrete Gannet

我同意。使用new EventArgs()会使下一个程序员的意图不太清晰，并且有点浪费。 - Jon Coombs