When working with files in C#, I am conditioned to think about freeing the associated resources. Usually this is a using statement, unless its a one liner convenience method like File.ReadAllLines, which will open and close the file for me.
.Net 4.0 has introduced the convenience method File.ReadLines. This returns an IEnumerable and is billed as a more efficient way to process a file - it avoids storing the entire file in memory. To do this I'm assuming there is some deferred execution logic in the enumerator.
Obviously since this method returns an IEnumerable, not and IDisposable, I can't go with my gut reaction of a using statement.
My questions is: With this in mind, are there any gotchas on resource deallocation with this method?
Does calling this method mean that the release of the associated file locks is non-deterministic?
IEnumerable
doesn't inherit from IDisposable because typically, the class that implements it only gives you the promise of being enumerable, it hasn't actually done anything yet that warrants disposal.
However, when you enumerate over it, you first retrieve an IEnumerator
by calling the IEnumerable.GetEnumerator
method, and typically, the underlying object you get back does implement IDisposable
.
The way foreach
is implemented is similar to this:
var enumerator = enumerable.GetEnumerator();
try
{
// enumerate
}
finally
{
IDisposable disposable = enumerator as IDisposable;
if (disposable != null)
disposable.Dispose();
}
This way, if the object does indeed implement IDisposable
, it will be disposed of. For File.ReadLines
, the file isn't really opened until you start enumerating over it, so the object you get from File.ReadLines
doesn't need disposing, but the enumerator you get, does.
As the comments indicate, IEnumerator
does not inherit from IDisposable
, even though many typical implementations does, whereas the generic IEnumerator<T>
does inherit IDisposable
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With