c# - Why *should* we use EventHandler -
i hate eventhandler. hate have cast sender
if want it. hate have make new class inheriting eventargs
use eventhandler<t>
.
i've been told eventhandler
tradition , blah, blah...whatever. can't find reason why dogma still around.
is there reason why bad idea make new delegate:
delegate void eventhandler<tsender, t>(tsender sender, t args);
that way sender
typesafe , can pass whatever heck want arguments (including custom eventargs if desire).
there reason requiring second argument derive eventargs
if fully-trusted code hosts third-party code partially-trusted.
because callback event handling delegate done in context of raising code , not third party code, possible malicious third-party code add privileged system operation event handler , potentially execute escalation of privilege attack running code in fully-trusted context partially-trusted context not run.
for example, if declare handler type int -> void
third-party code enqueue yourevent += enviroment.exit(-1)
, have exit process unintentionally. cause easy-to-detect problem, there far more malicious apis enqueued other things.
when signature (object, eventargs) -> void
there no privileged operations in framework can enqueued because none of them compatible signature. it's part of security code review in framework ensure (unfortunately cannot find source read this).
so in circumstances there valid security concerns why should use standard pattern. if you're 100% sure code never used in these circumstances event signature guideline isn't important (apart other developers thinking wtf), if might should follow it.
Comments
Post a Comment