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

我记得在多次和多个地点阅读时,在解雇典型事件时:

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

如果没有有趣的事件参数,则应该是EventArgs.Empty,而不是null.

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

1> Mitchel Sell..：

---

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

如果你传递null,并且该方法试图用e做某事,它将获得一个空引用异常,而EventArgs.Empty则不会.

---

如果一个方法可能传递事件信息而另一个方法可能不传 我仍然可以调用e.ToString(),但是一个可以传递自定义类型而另一个传递EventArgs.Empty

---

Greg,这里的重点是事件处理程序是*不是你的代码.您首先需要安全,因为您正在定义和提升事件,而其他人将编写事件处理程序.

---

围绕事件有公约和规范,如果不是保证.一个是EventArgs应该*never*为null,并且处理程序不应该检查它.

2> Martin Konic..：

---

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

基本上,使用一个表示"无值"的对象来避免在使用它时检查null.

3> ForCripeSake..：

---

我相信EventArgs.Empty用于维护使用事件传递参数的约定,即使不需要也是如此.

Mitchel Sellers在我的帖子中间发布了另一半我的理由:如果方法尝试并使用该参数执行某些操作,它会阻止空引用异常(除了检查它是否为null).

EventArgs.Empty 基本上完成全局定义的事件参数的工作,没有其他信息.

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

一个(略显迂腐)使用EventArgs.Emptyvs的原因new EventArgs()是前者没有初始化一个新的EventArgs,节省了少量的内存.

---

对于多次引发的事件(如MouseMove事件),"少量内存"可能很重要.