69

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

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

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

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

4

6 回答 6

35

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

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

于 2008-10-09T19:07:58.757 回答
27

EventArgs.EmptyNull 对象模式的一个实例。

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

于 2009-06-03T22:45:43.800 回答
8

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

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

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

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

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

于 2008-10-09T19:12:14.130 回答
2

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

于 2008-10-09T19:10:27.067 回答
0

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

于 2008-10-09T19:20:38.153 回答
0

来自阿尔巴哈里的书:"in order to avoid unnecessarily instantiating an instance of EventArgs."

于 2014-03-17T13:20:38.697 回答