Remove handlers on disposing object

Question

I can think of a few messy ways to solve this, but it strikes me that there should be a far more elegant solution than those which I've already come up with.

What's the most appropriate way for an object to cleanse itself of all of its event handlers prior to being disposed. It's a shame the event handler can't be enumerated upon.

In theory, is it considered more correct for the code adding the handler to an object to remember to remove it than assuming the object will clean itself up before it goes out of scope?

Answer 1

In theory, is it considered more correct for the code adding the handler to an object to remember to remove it than assuming the object will clean itself up before it goes out of scope?

To the above question, I'll have to say yes. The basic theory about events is that the event firer shouldn't be responsible for managing its own handlers; whoever added the event should do cleanup.

Answer 2

There is a way to avoid this common problem with events - WeakEvent pattern.

Answer 3

Event handlers are for me the biggest thread to memory consumption of a .NET application, especially if you start using it in a web server context. For me it is alwys the responsability of the object that attached itself to deattach. An attaching object should have always a smaller or equal life-span as the object it attaches to, otherwise there is a problem with the desing of the events as you don't want to be notified of changes in objects that have no meaning any more. If their lifespan is equal, they will go out of scope together and you don't need to do anything, if it is shorter then it the attaching object must detach. In a basic web application you only have 3 typeos of lifespans, application, session and page and the rules are easy to apply. In more complex applications this requires a bit more thinking.

Answer 4

In my designs I am quite strict about defining contracts like:

• each resource acquisition must be paired with a release
• each call to start a service must be paired with a call to stop the service
• each observer that attaches to a subject must detach
• and so on

(such contracts are not unusual, like you must pair the open and close of a file or pair new/delete calls in languages that do not employ automatic garbage collection).

Each of these contracts can be tested at run-time to some degree. For example, an observer detaching more times than it has attached can be detected and reported (assert or exception depending on the situation).

So, your question that:

In theory, is it considered more correct for the code adding the handler to an object to remember to remove it than assuming the object will clean itself up before it goes out of scope?

Is spot on. The answer is Yes, and not just in theory, but in practice too. In my opinion, these contracts help you avoid sweeping errors under the carpet.

Prescribe to this way off thinking and you are well on your way to building really robust software.