Question

可能重复：
Why should events in C# take (sender, EventArgs)?

我刚刚在一个项目上运行了VS2012代码分析工具，发现它抱怨这个代码段：

public delegate void PerMbHandler(long totalMb);

public event PerMbHandler NotifyMegabyteIncrement;

CA1009将“MyWebClient.PerMbHandler”的第二个参数声明为EventArgs，或者是一个扩展EventArgs的类型的实例，名为“e”。

事件处理程序方法有两个参数。第一个是System.Object类型，名为“sender”。这是引发事件的对象。第二个参数是System.EventArgs类型，名为“e”。这是与事件关联的数据。例如，如果在打开文件时引发事件，则事件数据通常包含文件的名称。

MSDN简单地说明了约定是什么，而不是它存在的原因。

使用 long 参数而不是 EventArgs 的子类会出现什么问题？这是一个常规和程序员期望的问题，还是有一些微妙的技术原因必须遵循这种模式？我说微妙，因为代码似乎工作正常。

Answer 1

使用long参数而不是子类可能会出错 EventArgs的？

事件参数
这本身并没有错，但它不可扩展。为了争论，也许在6个月内你需要传递两个长片，或者添加一个字符串，或者添加一整套信息。使用签名中的EventArgs，您可以传递任何派生类型，而不会破坏现有的使用者;具有特定值类型，您非常有限。

EventArgs还允许您与引发事件的类进行通信，例如CancelEventArgs。

<强>发件人
老实说，我很少使用发件人做任何事情。它也可能有些含糊不清。例如，通过输入文本框触发的控件上的自定义事件...谁是发件人？文本框（可能更有用），或声明自定义事件的控件？

尽管如此，这是一个熟悉的惯例，并且有一个记录良好的界面，它可能很有用。

Answer 2

没有什么可以出错，事件和事件处理程序签名是强类型检查的。所有的消息都警告你关于速度碰撞，这给了另一个使用你的事件的程序员，为什么事件有这样一个不寻常的签名感到困惑。速度颠簸会产生错误，程序员坚持认为他需要获取发件人。

请记住FxCop（又名“代码分析”）试图做的事情。它不检查错误，这是编译器的工作。它是让你知道你可能没有想过的事情。有时可能会有点麻烦，特别是当它面对CAS或不正当地标记臭名昭着的CA2000时。但这个肯定是一个很好的警告，你没有想到它。