c# - 为什么我们*应该*使用 EventHandler

Question

我讨厌 EventHandler。我讨厌我必须投 sender如果我想用它做任何事情。我讨厌我必须创建一个继承自 EventArgs 的新类使用 EventHandler<T> .

我一直被告知 EventHandler是传统，废话，废话……随便什么。但我找不到这个教条仍然存在的原因。

有没有理由说创建一个新的代表不是一个好主意:

delegate void EventHandler<TSender, T>(TSender sender, T args);

那样sender将是类型安全的，我可以传递任何我想要的作为参数(如果我愿意，包括自定义 EventArgs)。

Answer 1

如果您完全信任的代码以部分信任的方式托管第三方代码，那么实际上有充分的理由要求第二个参数派生自 EventArgs。

因为对事件处理委托(delegate)的回调是在引发代码而不是第三方代码的上下文中完成的，恶意第三方代码有可能将特权系统操作添加为事件处理程序，从而可能执行通过在您的完全信任的上下文中运行他们的部分信任的上下文无法运行的代码来进行特权升级攻击。

例如，如果您将处理程序声明为 int -> void 类型，则第三方代码可以将 YourEvent += Enviroment.Exit(-1) 和您是否无意中退出了该过程。这显然会导致一个易于检测的问题，但是有更多的恶意 API 可以排队执行其他操作。

当签名为 (object, EventArgs) -> void 时，框架中没有特权操作可以入队，因为它们都不与此签名兼容。这是框架中安全代码审查的一部分，以确保这一点(不幸的是，我找不到我读到这篇文章的来源)。

因此，在某些情况下，对于为何应使用标准模式存在有效的安全问题。如果您 100% 确定您的代码永远不会在这些情况下使用，那么事件签名指南就没有那么重要(除了其他认为 WTF 的开发人员)，但如果可能的话，您应该遵循它。