Destructor implemented via event

Question

I have several objects in our framework, that by the requirement need to provide event ObjectTerminated. The user of the framework can subscribe to this event and clean-up some unmanaged stuff, that he is using. These objects are designed to exist the whole life time of the application, and I'm not controlling their life. You can think of them as an array of singletons.

I want to write code like this:

class SomeWorkflowControlObject
{
     public event EventHandler<> ObjectTerminated;

     ~SomeWorkflowControlObject()
     {
          if (ObjectTerminated != null) ObjectTerminated(this, null);         
     }
}

I am not sure, am I allowed to do that. What could go possibly wrong with such solution?

Updated:

What about Process.GetCurrentProcess().Exited ? Can I use it in such manner?

Answer 1

You should not do this. Basically, destructors do not exist in C#. What you have written is a finalizer, and the only thing a finalizer should ever do is to free unmanaged resources.

You are not allowed to access any other managed object at all, since the garbage collector might already have removed it. I do not think your null check is a sufficient guard against this situation; that object reference might still point to your (event) delegate, even if it's already gone.

So in short, don't do this.

Alternatives:

1. Subscribe to the Application.ApplicationExit event if you have a Windows Forms application.

2. You might want to consider implementing the IDisposable interface instead and then do something like this:

   public class SomethingVeryLongLived : IDisposable
   {
       …
   }
   
   …
   
   public static void Main()
   {
       using (var sth = new SomethingVeryLongLived(…))
       {
           Application.Run(new SomeForm(…));
       } // <-- at this point, foo.Dispose() is guaranteed to be called.
   }
   

   Take note that even in the case of using IDisposable, it's probably not a good idea / design to trigger an event inside the object that is getting disposed, since disposed objects should no longer be accessed.

   For this very reason, I would recommend you do the following:

3. Use a try…finally block:

   public static void Main()
   {
       var sth = new SomethingVeryLongLived(…);
       try
       {
           Application.Run(new SomeForm(…));
       }
       finally
       {
           SomethingVeryLongLived.Terminate();
       }
   }
   

   This would seem best to me because you are not abusing the IDisposable interface, and it's very clear what the code does... there's no hidden meaning.

Answer 2

I believe the design of that framework is inherently flawed. Let me explain:

1. [...] several objects in our framework, that by the requirement need to provide event ObjectTerminated.

This doesn't make sense. If an object has been terminated, as the event's name suggests, then I would assume that it is already gone and that I can no longer access it. This raises two questions:

• How does something dead trigger an event? It's like a corpse talking to you from its grave, "I am dead." Do you really want this?

• Why would anyone else be interested in reacting to such an event, if the event sender is no longer supposed to be there? What is there to clean up after the corpse has already been buried?

2. I'm not controlling their life.

Who is controlling their lifetime, then? Why isn't it their responsibility to do, or trigger, the necessary clean up work at the appropriate moment? Let me further elaborate on this very point:

3. [...] can subscribe to this event and clean-up some unmanaged stuff [...]

Where is this unmanaged stuff, and which object is responsible for handling it? If it is your own object, then why doesn't your object dispose of it — why do you instead want to trigger an event, so that someone else can dispose of the stuff? It's like me carrying out my neighbour's garbage, instead of him doing it himself. (I'm not talking about an old lady there.)

Your class would make much more sense if it looked like this:

class SomeWorkflowControlObject : IDisposable
{
     // the following event doesn't make sense, sorry.
     // public event EventHandler<> ObjectTerminated;

     private IntPtr _handleToUnmanagedResource;

     ~SomeWorkflowControlObject()
     {
         Dispose(explicitly: false);         
     }

     public void Dispose()
     {
         Dispose(explicitly: true);
         GC.SuppressFinalize(this);
     }

     protected virtual void Dispose(bool explicitly)
     {
         if (explicitly)
         {
             // free managed resources here; perhaps trigger an event 'Disposing'.
         }
         DisposeUnmanagedResource(_handleToUnmanagedResource);
     }
}

That is, it is a wrapper around some unmanaged resource, for whose disposal it is responsible itself, and noone else. Thus, there is no longer a need to trigger an event, such that someone else can dispose the unmanaged resource, which should be hidden inside your object anyway.