Are there ever cases where you don't want to dispose of an IDisposable object that will go out of scope?

Question

I originally come from a C++ background where going out of scope means calling of a destructor and in that destructor is where you clean up everything. The destructor isn't a thing called later at some indeterminate time (like in C#).

New to C# I've been reading a lot about the disposable pattern (because I've made many many mistakes over the past year that resulted in huge amounts of unmanaged resources not being cleaned up resulting in spectacular crashing of programs) and frustratingly it seems like the language made it easier to accidentlly implement incorrectly than it did easy to accidentlly implement correctly.

Take for example:

public void DoSomething() {
    using ClassThatImplementsIDisposable obj = new ClassThatImplementsIDisposable();
    // do stuff
}

In the above (I think) I've implemented usage of a disposable class correctly. Namely that when I go out of scope the Dispose method will correctly be called because I added the using keyword.

But I find while developing that most of the time I remember to add the using keyword, but occasionally I might forget to add it resulting in unmanaged resource issues, which made me wonder:

Are there ever cases where I'd want to create an object that implements IDisposable AND that variable is going to go out of scope (and by going out of scope I also mean when the reference count goes to zero for objects that are passed around) AND I don't want it to dispose? For example:

public void DoSomething() {
    // is there ever a reason to purposefully leave off 'using'
    // here on a variable that will go out of scope
    ClassThatImplementsIDisposable obj = new ClassThatImplementsIDisposable();
    // do stuff
}

if there are cases for the above (which I can't think of any):

• Seem's to me the C# language would've been safer for programmers if they didn't give us the using keyword (which would mean all IDisposable objects would be implicitly disposed when reference count goes to zero) and instead maybe they give a notusing keyword for that weird case where you don't want to dispose (again asking if there are ever cases for this)

Answer 1

Of course there are, for example when you construct an IDisposable in a function, return it out and then the caller adds it to an array for safe keeping. As a really degenerate example of that, that's what constructors do.

Seem's to me the C# language would've been safer for programmers if they didn't give us the using keyword (which would mean all IDisposable objects would be implicitly disposed when reference count goes to zero)

Then you need to read up a lot more on how managed memory works. For one thing there is no reference counting, and for the other what you describe already happens today. The point of Dispose is to force it to clean up after itself in a deterministic fashion rather than when the garbage collector decides it's time. This is very important for OS handles like file handles, sockets, Sql Server handles, GDI+ drawing stuff, windows, etc.

Answer 2

In VS you could enable various rules, and specifically you could enable CA2000: Dispose objects before losing scope with severity Error to make your build fail in case of IDisposable object not disposed.

To enable it I created a .editorconfig file from Tools > Options > Text Editor > C# > Code Style > Generate .editorconfig, saving it in solution folder.

Then enabled CA2000 adding:

dotnet_diagnostic.CA2000.severity = error

Or simply open the .editorconfig file in VS and use the Analyzers tab.

Answer 3

Well you can't prove that something does not exist, so I can't say with certainty that there is no use case.

However, if you don't call Dispose, then at some point (that you don't control) the garbage collector will destroy the object for you. So there's no practical reason NOT to call dispose - you're just handing control of the disposition to the runtime.

There are definite practical reasons FOR calling dispose (proper release of unmanaged resources being a big one).

which would mean all IDisposable objects would be implicitly disposed when reference count goes to zero

They are, just not immediately since it can be done in the background when there is either memory pressure or enough spare resources to do it without bottlenecking the runtime.

Answer 4

Are there ever cases where I'd want to create an object that implements IDisposable AND that variable is going to go out of scope ... AND I don't want it to dispose?

That would be a misuse of the Disposable pattern.

I won't say no one has ever misused the pattern this way (DbDataReader and friends come to mind as an area where it's tempting), but it's definitely not something you find in every day code.

But something else in the question worries me:

I've made many many mistakes over the past year that resulted in huge memory leaks

IDisposable has NOTHING to do with memory. It is intended for use with unmanaged resources, and in .Net we have a garbage collector that is already there to manage memory.

In fact, most C# classes should have neither a Dispose() method nor a finalizer.

About the only exception to this is event handlers, where a subscription to an event may unintentionally hold a reference to an object, preventing the garbage collector from holding it. In this case, you might use IDisposable to clean this up.