While I see your position on using an integer, I, personally, disagree with this idea. By exposing “Disposed” to any other classes, including subclasses, you open up the possibility of your code behaving inappropriately.

Each class/subclass needs its own private tracking for safety purposes. This is the only way to guarantee proper tracking of disposal. I agree with this statement of yours: “would cause problems if the flag were exposed”. That is why I advocate that the disposed boolean should be private, not protected or public.

The disposed flag would be better as an integer, which could then be updated and tested via Interlocked.Exchange in the public Dispose method; a Disposed property could be exposed publicly which would indicate whether the flag was set.

One shouldn’t worry that a disposer which set the Disposed flag and threw an exception might prevent a finalizer from running, since classes which hold managed resources shouldn’t have finalizers in the first place.

It’s a matter of protection. The bool is a private implementation detail – technically, it’s only required if you have no way to tell via state that you’ve been disposed. That being said, by making it protected, a subclass could “undispose” you if it did something incorrectly. A protected property get method could be appropriate, as it prevents that case.

However, adding a protected property getter is not part of the “official” pattern. I was trying to stick to the official pattern here, which doesn’t include that. In that case, using your own disposed is required. For example, the above pattern works if subclassing a framework IDisposable – in which case you can’t change the base class.

-Reed