I'm implementing a .NET class which implements IDisposable. After being disposed, the object's state is invalid and so nobody should be accessing it, of course.

There are some situations where two essentially independent systems have access to the same instance of this class. One essentially "owns" the object but the other is charged with interacting with the object in a persistent manner.

If the "owner" opts to get rid of the object by calling Dispose on it, the other system needs to know about this because otherwise it may try to interact with an invalid object. It is not always convenient to have the owner inform the other system to stop using the object, because the owner itself may not know about this other system.

I do have the class implementing an IsDisposed property, but there are situations where polling this would become impractical and it would be preferable for the "non-owner" to instead receive notification that the object is disposed.

To this end I figured that implementing a Disposing event on the class would be a good solution, but this leads to some design questions:

  • Is the instance considered to already have been disposed at the time the event is raised? (My guess would be that it should be regarded as alive until the handlers finish.)

  • How should the object react to further manipulation that occurs inside the event handlers? (My guess is react in the usual manner for a living object since it is still alive.)

  • What if a handler itself calls Dispose on the object? (We could either explicitly ignore re-entrant calls or just assume that well-behaved handlers won't do this.)

  • Should the Disposed event still be raised in the event of the object being finalized without having ever been explicitly disposed? (I can't think of a case off hand where such an event would actually be needed, and it definitely has the potential to cause problems.)

I'm wondering if there is any established wisdom on how this pattern should be designed in general, or any examples I should be aware of where trouble is likely.

  • Are you holding unmanaged resources in your class? Mar 19, 2013 at 21:53
  • @RobertHarvey Yes; the class is part of an unmanaged game engine's API. The object represents a viewport on the screen and holds a pointer to the engine's C++ viewport class. I think part of the problem is that disposing the object has a time-sensitive side-effect: making the viewport leave the screen. When code "owning" the viewport wants to take it off the screen, it calls Dispose on the associated object. I should probably have a Close method, but the engine design is such that the port is either on the screen or doesn't exist at all, so in that sense Dispose made more sense than Close.
    – Kevin
    Mar 19, 2013 at 23:06
  • I don't see why this wouldn't work. I updated my answer accordingly. Mar 19, 2013 at 23:13

2 Answers 2


Linq to SQL had a related issue, having to do with lazy evaluation. If data was requested after the DataContext was disposed (which can happen if the query is lazily evaluated), an exception was thrown.

The solution was to not dispose of the data context, and allow the garbage collector to collect it naturally. See http://leedumond.com/blog/about-disposing-the-datacontext/

Strictly speaking, you do not need the dispose pattern unless you are holding unmanaged resources. Unmanaged resources are not automatically cleaned up by the garbage collector, so you have to do that yourself. Of course, this hasn't prevented some very smart people from abusing the using pattern for fun and profit.

All that said, I don't see any reason why you couldn't fire an event from the Dispose() method. You can pass the object being disposed through the event handler and, as long as your event handler doesn't hold onto the object for too long, dispose of your managed resources when the handler returns.

  • That bit about IDispose being used to close an HTML tag gave me confidence that nothing I will ever do will be truly absurd. :) I'm thinking most times needing a 'Disposing' event is probably avoidable; nevertheless it did work without issue.
    – Kevin
    Mar 20, 2013 at 3:01

I'm pretty sure it's in the Framework Design Guidelines somewhere, but what I've observed is that whenever an object gives you a Disposable, it does not interact with it anymore. Usually, there is a static method call that is responsible for creating and handing the disposable to you.

There are two options you have here:

  • Your "owner" should never expose the IDisposable and should instead act as an Adapter over it. (In other words the client calls the "owner" who then delegates the calls to the IDisposable).

  • Your "owner" should be a factory and should just be responsible for creating an instance of the IDisposable, doing any additional configuration, and handing it to the client never storing a reference to it.

  • +1 for good points in general. This does however assume the "non-owner" is a client of the "owner." Actually in this case it happens to be closer to the other way around: the "non-owner" is performing more basic services and wouldn't know to use the "owner."
    – Kevin
    Mar 20, 2013 at 3:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.