Singleton having finalizer without IDisposable

Question

Here's what I understand about IDisposable and finalizers from "CLR via C#", "Effective C#" and other resources:

• IDisposable can clean up managed and unmanaged resources deterministically.
• Classes responsible for unmanaged resources(e.g. file handles) generally implement IDisposable and provide a finalizer to guarantee their clean up even if client codes did not call Dispose() on the instance.
• Classes responsible for only managed resources must not implement a finalizer.
• If you have a finalizer then you must implement IDisposable (so that client codes can also call Dispose(), while the finalizer is just to prevent leaking resources in case they forget).

Now, I can understand the reasons behind each of the above, but then I also believe there could be a scenario where breaking these rules might make more sense. Like, say, a singleton class that is responsible for unmanaged resources (such as in cases of providing a single point of access to particular files). I think it'll be wrong to always have a method Dispose() on a singleton because that singleton instance must live for the life of the application and if any client code calls Dispose() then that does it and you are stuffed. However, you'd still want a finalizer that will clean up unmanaged resources when the application is unloaded. Thus, a singleton class with a finalizer that does not implement IDisposable seems more ideal and reasonable to me. Yet, this design completely goes against what the best practices have to say.

Please advice on whether this is a reasonable approach or not? And, if not, why and what could be other superior alternatives?

Answer 1

You wouldn't even need a finalizer if you released unmanaged resources only on application exit as then, the process unload would deal with them for you automatically.

Now, dealing with an app domain unload while having multiple app domains could become an issue but possibly one that you don't need to worry about.

I also agree that this type of design is probably not the right thing to do(will make it harder to fix, and subsequently you'll find yourself needing two instances). You could create the object (or just a lazy loading wrapper object) in your entry point and only pass it through the code to when and where it's needed, making it very clear as to who is responsible for providing it to whom. Then, you could always be free to change the decision of using only one instance with little effect to rest of the code(which only uses what it's given).