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

Popular posts from this blog

ASP.NET/SQL find the element ID and update database -

jquery - appear modal windows bottom -

c++ - Compiling static TagLib 1.6.3 libraries for Windows -