There are several discussions here on StackOverflow about what to do if my object manages other managed objects that implement System.IDisposable
.
Note: Below I am not talking about unmanaged code. I fully understand the importance of cleaning up unmanaged code
Most of the discussions say that if your object owns another managed object that implements System.IDisposable
, then you should also implement System.IDisposable
, in which case you should call the Dispose()
of the disposable objects your object holds. This would be logical, because you don't know whether the disposable object you own uses unmanaged code. You only know that the creator of the other object thought it would be wise if you'd call Dispose
as soon as you don't need the object anymore.
A very good explanation of the Disposable pattern was given here on StackOverflow, edited by the community wiki:
Proper use of the IDisposable interface
Quite often, and also in the mentioned link I read:
"You don't know the order in which two objects are destroyed. It is entirely possible that in your
Dispose()
code, the managed object you're trying to get rid of is no longer there."
This baffles me, because I thought that as long as any object holds a reference to object X, then object X will not and cannot be finalized.
Or in other words: as long as my object holds a reference to object X I can be certain that object X is not finalized.
If this is true, then why could it be, that if I hold the reference to my object until my finalize, the object I refer to is already finalized?
The truth is somewhere between the two:
If object X refers to object Y, but both are finalizable, then it's entirely possible for object Y to be finalized before object X, or even for them to be finalized concurrently.
If your assumption were correct, then you could create two objects which refer to each other (and have finalizers), and they could never be garbage collected because they could never be finalized.
See more on this question at Stackoverflow