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.