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

我记得在多个场合和多个地点阅读时发现这个典型事件:

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

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

我遵循我的代码中的指导,但我意识到,我不清楚为什么这是首选的技术。

  1. 为什么说明的合同更喜欢EventArgs.Empty over null?
  2. 在我自己的代码中,什么样的情况会certificate类似的devise决定是正确的? 什么时候应该考虑创build一些静态的“Nothing interesting here”属性,而不是使用null来表示没有什么有趣的东西?
  3. 增加了可为空值的types是否会影响这些决策?

我相信NOT NULL背后的原因是,当作为parameter passing时,并不期望该方法需要潜在地处理空引用exception。

如果你传递null,并且该方法试图用e来做一些事情,它将得到一个空的引用exception,而EventArgs.Empty则不会。

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

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

我相信EventArgs.Empty用于维护传递参数与事件,即使没有需要的约定。

Mitchel Sellers在我的文章中途发布了另外一半的理由:如果一个方法试图用这个参数来做一些事情(除了检查它是否为空),它可以防止null引用exception。

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

编辑

为了给出一个维护约定的类似例子,我们的团队使用string.empty来初始化stringb / c,否则不同的编码器可能会使用newString = ""; or newString = " "; or newString = null; newString = ""; or newString = " "; or newString = null;

所有这些在不同的检查条件下可能产生不同的结果。

编辑#2

使用EventArgs.Empty和new EventArgs()的一个(稍微迂腐)理由是前者不初始化一个新的EventArgs,保存less量的内存。

如果您使用的通用方法具有从任何事件处理程序调用的EventHandler签名,并且同时传递了object senderEventArgs e ,则可以调用e.ToString() (例如,logging事件),而不用担心一个空指针exception。

我用了很长时间的“新EventArgs()”,而不是“EventArgs.Empty”…我认为重要的是传递一些不会导致Nullexception。

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