Where to "destroy" Handlers in VB.NET classes?

Question

I have some class (a user control) MyUserControl that rises events.

I use it in a form MyForm, in that, for some reasons I am forced to use AddHandler instead of WithEvents<>Handles pair.

I use AddHandlers in the MyForm_Load method.

Now. Adding handler is OK, the question now is where to remove this handler. Should it be done in the Finalize method of MyForm? à la

Protected Overrides Sub Finalize()
  RemoveHandler _myCtrl.Action1Performed, AddressOf MyControl_Action1Performed  
  RemoveHandler _myCtrl.Action2Performed, AddressOf MyControl_Action2Performed  
  RemoveHandler _myCtrl.Action3Performed, AddressOf MyControl_Action3Performed  
End Sub

Answer 1

When the container control (such as your form) is disposed, all of its event handlers will be automatically removed and disposed. This cleanup happens for you automatically because neither your user control nor its container form exist anymore.

The only time you really need to worry about calling RemoveHandler is if you're hooking up event handlers to objects that are expected to have a significantly longer lifespan than their containers. In that case, it's possible to create a memory leak because that object cannot be garbage collected as long as that handler is subscribed. You can read a much more comprehensive case study here on Tess Ferrandez's blog. This is not a problem if both objects go "out of scope" at the same time.

EDIT: If you still feel that you absolutely need to remove the handler (perhaps you're obsessive compulsive?), you can go ahead and do it in the form's Dispose method. A purist might balk at the use of IDisposable for something like this, but you won't see any ill results. You do want to make sure that you don't implement the Finalize method for this, though. There's just no point: the finalizer method won't get called until there are no more strong references to the object, but the only possible harm in failing to call RemoveHandler is that a container will hold onto a reference to that object longer than necessary. You're fooling yourself by trying to remove event handlers in the Finalize method.

Also keep in mind that it really doesn't matter where exactly you do it, because the purpose of AddHandler/RemoveHandler is to allow you to add and remove event handlers dynamically. You're allowed to call them anywhere in your code that you want.

Answer 2

not sure why you removing the handlers, unless you are no longer needing them on the next post back and you conditionally set them again on page load, otherwise if you are using them for each post back, you should just let the GC handle the disposal

Answer 3

Assuming your Form is the owner of the UserControl(s), you don't need any cleanup at all.

If you had handlers like AddressOf OtherObject.Action1Performed and OtherObject lives longer than the Form, then you should remove the handler.

---

Edit:

About the 'where' : Not in a Sub Finalize .

You can use the Dispose() method (in C# you can move it from the Designer file). Otherwise, use the FormClosed event.

A finalizer is not needed here, but it does come with considerable costs.

Answer 4

An object's finalizer will be useless for cleaning up that object's event subscriptions. It won't fire until all the publishers of all the events to which the object subscribes have gone out of scope themselves, and once that has happened the issue of cleaning up the events will become moot. Creating a finalizer for this purpose will actually be counter-productive since a finalizable object will delay the garbage-collection of itself and any object to which it holds a direct or indirect reference.

I would consider it a good practice to clean up event subscriptions as a matter of habit. While one might regard event subscriptions as a managed resource if the publisher and subscriber have equal lifetimes, events from long-lived objects are an unmanaged resource. They should be cleaned up in Dispose if they're not cleaned up elsewhere (and Dispose should be a 'back-stop' to cleanup elsewhere). While one can get away with ignoring event subscriptions for short-lived objects, such a practice requires identifying which event publishers are, or may be, long-lived. Note also that routinely unsubscribing from events when objects go out of scope will limit the damage that can be caused if an occasional event is missed. If events from supposedly-short-lived objects are abandoned, but one long-lived object's event is abandoned as well, none of the short-lived objects may become eligible for garbage collection until the long-lived one does.