Shouldn't Dispose method get called automatically?

[Zen]

Hi,

Would anyone know why the .net language would just issue calling the Dispose
method to all objects going out-of-scope if they implement IDispose. In
another word, if the "using" statement is implicit and automatic for all
scope then it would resolve many unmanaged resources leaking or unnecessary
accumulation. Why was it designed so that programmers have to go through the
process of finding out which one implementing IDispose and call on it?

Thanks!

 

[Zen]

I meant "why the .net languages would *not* just issue calling the
Dispose...?"

 

[Greg Young]

public void Bar(SomeDisposable t) {
instancevariable = t;
}
public void foo() {
SomeDisposable t = new SomeDisposable();
somestatic.Bar(t);
}

obviously when t falls out of scope we do not want to automatically dispose
of it as someinstancevariable still has a reference to it ... as such we
rely on garbage collection and reference counting.

If you put a finalizer on the disposable object you can have the garbage
collector automatically call your dispose, which I assume is the basic point
of your question.

http://www.theserverside.net/articles/article.tss?l=GarbageCollection
contains more info for you on using finalizers in conjunction with
IDisposable.

We use IDisposable so we can explicitly (and deterministically) tell the
object to release its resources as opposed to waiting on the garbage
collector. The Image class is a great example of this .. when you call
Image.FromFile() the file remains locked until the image object is disposed;
as such we don't want to wait for the garbage collector to find the object
to dispose (and release the lock) so we explicitly tell the object to
dispose when we are done using it.

Cheers,

Greg Young
MVP - C#

 

[Jay B. Harlow [MVP - Outlook]]

Zen,
| Would anyone know why the .net language would just issue calling the
Dispose
Do you mean any .NET language or C# specifically? As there are 20+ .NET
languages available.

Both C# & VB have the using statement to call IDisposable automagically.

While C++/CLI will call it for you using regular variable declaration.

For example:

// causes C++/CLI to call Dispose when theConnection goes out of scope
// also causes a new theConnection be created for you...
SqlConnection theConnection;

// requires you call Dispose when theConnection goes out of scope
SqlConnection^ theConnection;

The biggest danger of always calling Dispose is when you create an object
and assign it to another object & then return the other object. For example:

SqlConnection theConnection = ...;
SqlCommand theCommand = ...;

theCommand.Connection = theConnection;
return theCommand;

We really don't want theConnection disposed in the above sample!

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Hi,
|
| Would anyone know why the .net language would just issue calling the
Dispose
| method to all objects going out-of-scope if they implement IDispose. In
| another word, if the "using" statement is implicit and automatic for all
| scope then it would resolve many unmanaged resources leaking or
unnecessary
| accumulation. Why was it designed so that programmers have to go through
the
| process of finding out which one implementing IDispose and call on it?
|
| Thanks!
|
|
|
|

 

[Sericinus hunter]

Hi,

Would anyone know why the .net language would just issue calling the Dispose
method to all objects going out-of-scope if they implement IDispose.

If object goes out of scope, it doesn't mean that it cannot be referenced
by something from outside the scope.

 

[Zen]

Thanks for the responses, true, but the .net framework can ref-count the
objects, right? All objects must belong to the scope including the one that
hold a reference to a local scope. That way, when an object is going out of
scope, the ref count is going down by 1, if it hits 0, the framework would
just recursively walk down to the members of the objects and decreases their
own ref-count by 1, any of them hitting 0 will have their Dispose method
called (after their children are done with it)

I think that would be far more better than waiting for the finalizer process
to be called as it's currently done. Memory collection is relatively fine to
wait for GC to finally kicks in but the unmanaged resource is a different
story. Although, GC, in my limited experience and knowledge, is not
frequently enough - even in the case of my app receiving Out-of-memory
exception, GC doesn't seem to jump in. I have to trap those exceptions then
explicitly call GC.GetTotalMemory(true) when i receives then.

 

[Mattias Sjögren]

but the .net framework can ref-count the objects, right?

In theory it could, but it doesn't. .NET doesn't use reference
counting. People have tried implementing it on top of the CLI but it
didn't work very well.


Mattias

 

[Chris Chilvers]

When nothing is referencing an object its finalizer will be called. For
an object that implements IDisposable it should call Dispose().

This is ok as long as those resources are not limited or expensive, at
which point you may not want to wait until the GC gets round to
collecting them.

Also what about cases such as SqlConnection which is provided by a
shared pool. In this case the pool always contains a reference to it so
that the connection can be reused later. Now you have to call Dispose
(or Close) to tell the pool that the connection is no longer in use and
can be re-used by something else.

 

[Zen]

I'm not sure if you were answering my question or disagreeing with what I
brought up. I don't think it's a necessary for programmers to worry about
or remember to call Dispose() explicitly in theory. If they just miss one,
then a disaster can be waiting to happen, an small object can be a root of a
deep and huge inventory of unmanaged resources or a just few key resource
that can block other things to run smoothly. GC was designed so that
programmers don't have to worry about memory collecting but unmanaged
resource often more important to be automatically and quickly colllected (or
a less error prone way to be quickly collected).

 

[Zen]

do you have more details on why it didn't work very well? thanks!