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

Question

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

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

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

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

Answer 1

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

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

如果一个方法可能传递事件信息而另一个方法可能不传我仍然可以调用e.ToString(),但是一个可以传递自定义类型而另一个传递EventArgs.Empty (6认同)
Greg,这里的重点是事件处理程序是*不是你的代码.您首先需要安全,因为您正在定义和提升事件,而其他人将编写事件处理程序. (4认同)
围绕事件有公约和规范,如果不是保证.一个是EventArgs应该*never*为null,并且处理程序不应该检查它. (3认同)

Answer 2

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

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

Answer 3

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

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

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

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

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