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

67

我回想起在多个场合和多个位置读到的关于触发典型事件的信息：

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

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

我遵循了代码中的指导，但是我意识到我不清楚为什么这是首选技术。为什么指定的合同比空值更喜欢EventArgs.Empty？

c# events eventargs

— 格雷格·D
source

33

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

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

— 米切尔卖家
source

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

— 格雷格D

6

如果一种方法可以传递事件信息，而另一种则不能。无论如何，我仍然可以调用e.ToString（），但是一个可以传递自定义类型，另一个可以传递EventArgs.Empty

— Mitchel Sellers

4

Greg，这里的重点是事件处理程序不是您的代码。您首先要安全，因为您正在定义和引发事件，其他人将编写事件处理程序。

— 混凝土塘鹅

3

关于事件，有约定和规范（如果不能保证）。一种是EventArgs绝不能为null，并且处理程序也不必检查它。

— 混凝土塘鹅

28

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

基本上，有一个表示“无值”的对象以避免在使用它时检查是否为空。

— 马丁·科尼切克
source

7

我相信EventArgs.Empty，即使不需要任何东西，也可以用来保持将参数传递给事件的约定。

Mitchel Sellers在我的帖子的一半发布了我的另一半理由：如果方法尝试对该参数执行某项操作（除了检查它是否为null之外），它可以防止null引用异常。

EventArgs.Empty 基本上是在没有其他信息的情况下完成全局定义的事件参数的工作。

为了给出类似的约定惯例，我们的团队使用string.Empty了初始化字符串的方法，因为否则可能会使用不同的编码人员newString = ""; or newString = " "; or newString = null;，所有这些人员对于不同的检查条件可能会产生不同的结果。

使用EventArgs.Emptyvs的一个（有点古怪的）理由new EventArgs()是前者不初始化新的EventArgs，节省了少量的内存。

— 煎饼
source

2

对于多次引发的事件（如MouseMove事件），“少量内存”可能很重要。

— 混凝土塘鹅

EventArgs.Empty是否不返回对EventArgs新实例的引用？那么节省内存的来源是什么？

— 约翰·史密斯

2

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

— 马克·西达德
source

0

我使用了很长时间的“ new EventArgs（）”而不是“ EventArgs.Empty” ...我认为重要的是传递不会导致Null异常的内容。

— 帕特里克·德斯贾丁斯
source

5

EventArgs.Empty不为null，它是一个用“ new EventArgs（）”初始化的静态变量。这意味着您不会浪费资源来初始化没有变化值的有效占位符对象。

— ICR，

3

如果EventArgs中没有有意义的数据，请不要实例化。EventArgs.Empty可以完成这项工作，而无需创建只会被垃圾收集的无用对象的开销。

— 混凝土塘鹅

我同意。使用新的EventArgs（）会使下一个出现的程序员的意图不太清楚，这有点浪费。

— 乔恩·库姆斯

0

从阿尔巴哈里书： "in order to avoid unnecessarily instantiating an instance of EventArgs."

— Bobak_KS
source

3

null不会实例化的实例EventArgs。

— 格雷格D