为什么使用EventArgs.Empty而不是null？ [英] Why use EventArgs.Empty instead of null?

问题描述

 保护虚拟OnSomethingHappened（在一个多个位置， ）
 {
 this.SomethingHappened（this，EventArgs.Empty）; 
} 
  

e应该是EventArgs.Empty，如果没有有趣的事件args，不是null

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

1. 为什么说明的合同更喜欢
   EventArgs.Empty over null？


2. 我自己的$ b有什么样的情况$ b代码可以证明类似设计
   的决定？什么时候应该考虑
   创建一些静态的没有
   有趣的属性而不是
   使用null表示缺少
   有趣的东西？


3. 添加可空值类型是否影响了这些决定？

解决方案

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

如果你传递null，并且该方法试图用e做某事，它将得到一个null引用异常，EventArgs.Empty不会。

I recall reading, on multiple occasions and in multiple locations, that when firing the typical event:

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

e should be EventArgs.Empty if there are no interesting event args, not null.

I've followed the guidance in my code, but I realized that I'm not clear on why that's the preferred technique.

1. Why does the stated contract prefer EventArgs.Empty over null?
2. What sort of situations in my own code would justify a similar design decision? When should I consider creating some static "Nothing interesting here" property instead of using null to indicate the absence of something interesting?
3. Has the addition of nullable value types impacted these decisions?

解决方案

I believe the reasoning behind the NOT NULL is that when passed as a parameter, it is not expected for the method to need to potentially handle a null reference exception.

If you pass null, and the method tries to do something with e it will get a null reference exception, with EventArgs.Empty it will not.

这篇关于为什么使用EventArgs.Empty而不是null？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！