Paneque's Technology Blog

This is  the second and final part of this series. Will focus now a bit on what happen when we add multithreading to our work with events. Cleaning Up Events and Context Information In the previous post I mentioned some issues using lambdas and anonymous methods on events. The unsubscribe problem had a tricky "solution" by declaring a "cleanup" method inside the class that holds the event. public void CleanupSubscribers() { SayHelloCompleted = null; } The problem here is obvious since the cleanup method will remove all subscribers from the event. Hence, individually removing listeners from the event gets tricky when using lambdas/anonymous methods. So in this case the recommendations would be: Do not use lambdas if you need to unsubscribe. If you do so, use the cleanup method UNLESS your code is multithreaded.  NOTE: this only applies to the use of lambda expressions and anonymous methods, as for regular named methods yo...

Combining lambdas, anonymous methods and events feels natural in C#, and we use them almost as a reflex, they help us to create closures and avoid creating state variables outside the scope of our methods or passing extra state data through event calls. But one thing that come with events is the fact that writing good applications implies making good use of the resources, meaning we have to dispose those we no longer need. When using events with lambdas and anonymous methods, is possible to forget about that, thus writing code that is not efficient and prone to crashes. Will start this 2-part series talking about the subscribe/unsubscribe behavior. Subscribe/Unsubscribe lambdas and anonymous methods Let's begin with a basic scenario using events in a single-thread context for now; just to keep it simple. The code fragment below contains the HelloEventArgs implementation as well as the publisher class MyClassWithEvents . public class HelloEventArgs:EventArgs { ...