High maintenance

re: High maintenance

Michael Ratanapintha — Mon, 08 Sep 2008 21:09:14 GMT

This is just picking nits, but there may be reasons why you want to give this method a Stream, or a text Reader, instead of a filename. Obvious examples: a socket, a named pipe, a String, or an in-memory buffer.

Also, I'm somewhat surprised that, as shown in the original, StreamReader even has a BaseStream property. If the StreamReader owns its Stream, then why is the Stream even being exposed for the client to muck around with?

re: High maintenance

Eric Lippert — Mon, 08 Sep 2008 21:57:40 GMT

In the particular case, the code was being used ONLY to read from text files on disk. Better to not be prematurely general, as premature generality got the author of this code into trouble in the first place.

If you were to design a Lines() method that took an arbitrary reader, it would be a good idea to explicitly document that the returned enumerator owns the reader and will close it when it is done.

To answer your question -- yes, this is a bit of a leaky abstraction, isn't it? And quite dangerous. But one can imagine situations in which code handed a stream reader might want to interrogate the underlying stream for interesting facts about it before blindly calling the streamreader methods on it -- like "just how big is this stream?", so that the code could put up a user interface element saying how much more of the stream there was to be processed, and so on.

re: High maintenance

configurator — Mon, 08 Sep 2008 22:03:44 GMT

I agree with Michael.

- but -

The stream can also be used in a much better way, simply by adding a using (reader) around the body of the function. Also, I'd remove the seek, and add an XML comment stating that the function returns the rest of the lines up to the end of the stream, then disposes of it.

I'd also like to point this out: using 'using' in iterator functions is perfectly unsafe. This is the one scenario that eludes the semantics of 'using'. Whenever we use using, we know that when used 'properly', the object will always be disposed as soon as possible. But when will it dispose if we happen to read only halfway through the file, then break out of the foreach loop, or even throw an exception? It seems that the iterator object would still be alive until GC collects it, wouldn't it? And as long as the iterator object is alive, the function will be stuck in mid-execution, meaning that it would not exit the using block and not dispose of the file. Am I missing something here?

re: High maintenance

Jonathan Pryor — Mon, 08 Sep 2008 22:21:45 GMT

`using` within iterators is safer than you give it credit for.

If someone uses `foreach' and breaks out of the loop early, the `using' will still work.

If an exception is generated from the `foreach', the `using' will still work.

The reason both of these work is because IEnumerator<T> implements IDisposable, and the generated iterator .Dispose() will execute the `finally' block of the `using' statement. Try it; it works.

The only time that `using' won't work is if you (1) forego `foreach` (i.e. manually reimplement foreach), AND (2) forget to .Dispose() of the iterator.

Doing both (1) and (2) is possible, but I would suggest that it's not very likely.

re: High maintenance

Muhammad — Mon, 08 Sep 2008 22:29:13 GMT

Hello Eric,

thanks much - as always, very interesting post.

it would be great if you can explain 2 points:

1- why do you have a private & public interfaces?

2- and I didn't get your first objection (Namely, the null check is not performed when the method is called)?

how is the check for null different between original and corrected implementations?

re: High maintenance

kostat — Mon, 08 Sep 2008 22:30:45 GMT

to configurator:

yes, you are. I asked a very same question, but looked to IL first. IEnumerator<T> is IDisposable, so you should dispose it by contract when you are done and foreach does it correctly. Even though non generic IEnumerator is not IDisposable (BCL flaw), for foreach the compiler does a good job by checking if it 'is' IDisposable.

Kosta

re: High maintenance

Eric Lippert — Mon, 08 Sep 2008 22:33:10 GMT

Jonathan is correct. Remember, foreach(A b in c) D(b); is actually codegenned as though you had written something like:

{
E e = c.GetEnumerator();
try
{
while(e.MoveNext()) { b = (A)e.Current; D(b); }
}
finally
{
e.Dispose();
}
}

Disposing an enumerator causes any not-yet-run finally blocks in the iterator block to run.

So in both the cases you describe, the reader would be disposed immediately upon prematurely leaving the foreach, whether via exception, break, goto, or return.

re: High maintenance

Eric Lippert — Mon, 08 Sep 2008 22:36:00 GMT

Muhammad:

1) The public method checks its argument. The private method does not. Don't expose two methods which do the same thing, but where one is safe and the other is dangerous.

2) Since the iterator block does not run until the first MoveNext, the check for null doesn't happen until possibly long after the call to Lines(). You want the check to happen immediately so that if it is going to fail, it fails at the earliest possible point. That is, consider the original code called like this:

StreamReader reader = null;
var lines = reader.Lines(); // you expect it to throw here
// ...
foreach(var line in lines) // but it actually throws here, because the iterator block doesn't run until the first MoveNext. This could be in completely different code and long after the call to Lines(), which is confusing.

re: High maintenance

Eric Lippert — Mon, 08 Sep 2008 22:39:31 GMT

Now, in the interests of full disclosure, note that this is "unsafe" in the sense that we have many times shipped bugs where the codegen for some cases does not correctly run the finally blocks when something disposes of an iterator halfway through. The codegen for these cases is the single hardest part of the compiler and we've screwed it up in the past. For example, there were cases with nested finally blocks where the finally blocks would run in the wrong order.

If anyone finds such bugs in the service release of the compiler, PLEASE tell me about them.

re: High maintenance

RichB — Mon, 08 Sep 2008 22:44:19 GMT

Wow - you managed to say all of that without once mentioning 'invariant' :-)

BTW - any reason for inferring the type of 'reader' using 'var', while you declared 'line' directly as a string? What reasoning did you have for declaring the two variables in different ways?

re: High maintenance

Eric Lippert — Mon, 08 Sep 2008 22:49:05 GMT

RichB: It is dead obvious from the initialization of reader what the type will be. The "new StreamReader" sitting right there tells you what the type is. Stating the type is completely redundant for reader.

But it is not obvious from just the initialization of "line" that it will be a string. In that case you have to know what type ReadLine returns. By stating "string" explicitly it makes it obvious to the reader that my intention was for this thing to be a string.

re: High maintenance

Jonathan Pryor — Mon, 08 Sep 2008 23:08:07 GMT

As for the original design of Lines(), my biggest beef is that it mucks around with .BaseStream, which is evil (for all the reasons mentioned).

My 2nd beef, though, isn't mentioned: .Lines() is on StreamReader.

It _should_ be on TextReader, which would allow us to do:

foreach (var line in Console.In.Lines ()) { ... }

Which just seems perfectly natural to me.

Which further makes things more complicated about the `ownership` argument: .Lines() certainly should NOT be disposing of Console.In when it's complete, as Console.In is managed by the runtime.

Which says to me that .Lines() shouldn't "own" the TextReader, at least not by default.

I'm also not sure it's a "leaky abstraction," either, as all .Lines() is documented to do is extract lines of text from the input, NOT to actually own the input (as it may be ideal to reuse the existing StreamReader instead of creating a new one).

(As for "Readers are cheap," I'm not entirely sure of that, unless you also argue that HANDLEs are cheap. Since a StreamReader owns the underlying Stream, and a Stream is a kernel HANDLE to a file, by definition multiple readers will require multiple kernel HANDLEs. Plus you'll need to provide the appropriate flags to the FileStream constructor, lest you only be able to have *one* FileStream open for that file (the FileShare enumeration), which would kill your "multiple readers" defense rather quickly...)

I think there is one problem most apparent, though: FileUtilities.Lines() shouldn't be necessary. In particular, File.ReadAllLines() should have done this in the first place! Who's brilliant idea was it to make File.ReadAllLines() return a string[]? That design decision restricts any actual improvement in that method, AND requires that the entire file be loaded into memory at once. Brillant!

re: High maintenance

Rik Hemsley — Mon, 08 Sep 2008 23:47:23 GMT

Really nice rewrite of the original code. I'd be proud if I'd done the same.

re: High maintenance

Eric Lippert — Tue, 09 Sep 2008 01:31:35 GMT

Well, again, it comes down to "premature generalization is evil". The purpose of the code was "open a bunch of files for reading and read them in one line at a time", and when you write code that implements something more general than that, then you have all the design, implementation and testing burden of ensuring that your system works with ANYTHING that can be a TextReader instead of merely anything that can be a file name.

If you wanted this system to work on arbitrary text readers then you would need to decide and document who owns the thing and whether or not it is closed when you're done reading; if you need to impose the tax of the caller keeping ownership of the reader then that's a consequence of having to solve the more general problem. Generality is expensive, and therefore to be avoided if it cannot be made cheap.

As for the design flaw in "lines" in the first place -- you will get no argument from me. I have a separate rant queued up about methods that return arrays. However, keep in mind that this method was invented before generic types were added to the CLR. Obviously today you would use IEnumerable<string>, but in CLR v1, that was not an option.

re: High maintenance

Jonathan Pryor — Tue, 09 Sep 2008 03:07:08 GMT

The method may have been *designed* before CLR v2.0 (who's to say for sure outside of Microsoft?), but it wasn't *introduced* until .NET 2.0:

http://msdn.microsoft.com/en-us/library/s2tte0y1.aspx

"Supported in: 3.5, 3.0, 2.0"

Even if it were in 1.0/1.1, it could have returned an IEnumerable, which would allow future alteration of the method's implementation, as opposed to (effectively) leaking implementation details to one and all. Alas, this wouldn't be strongly typed, but it would allow migrating the implementation from an array-based to a C# iterator based implementation. The only downside is you lose type safety. :-(

(You also lose array indexing, which makes it ~trivial to write out a line along with it's corresponding line number. Providing the line number is easy without arrays, but not _as_ easy.)

(I think this would also be in keeping with the FxDG: Section 5.7 says "DO use the least derived parameter type that provides the functionality required by the member." A return type isn't a parameter, but I believe the the same basic idea holds true: return the type that provides you the greatest future flexibility. string[] has _no_ future flexibility, while IEnumerable does.)

iirc, there are several other methods added in 2.0 which return non-generic types where it really would have made more sense. It seems that not everyone got the `C# iterator` love memo (while LINQ is predecated upon lots of C# iterator love, so I guess that makes up for it).

(Furthermore, many v1.0 types haven't been retrofited to support the v2.0 generic interfaces, e.g XmlNodeList.)

re: High maintenance

peted — Tue, 09 Sep 2008 03:39:59 GMT

I agree with the general sentiment. But I do take issue with a couple of comments:

" No one should be messing with that stream but the reader."

Well, for better or worse, .NET is specifically advertising this as a feature. The StreamReader provides no API itself to manage position within the stream, does provide the BaseStream property as well as the DiscardBufferedData method. The intent of the contract for StreamReader is clearly to allow random-access to the stream, and to do so by virtue of allowing the client of the StreamReader to manage the position, rather than having the StreamReader itself do it.

I suppose you could argue that the .NET design is flawed. But it is what it is, and when used carefully there's nothing inherently wrong with this use of StreamReader.

Also:

"Maybe the caller knows that there are a bunch of bytes that it wants to skip, so it deliberately hands a StreamReader to Lines() which has been positioned somewhere past the beginning of the file. But Lines() thinks that it knows best and ignores the information that the caller has given it."

As an interface goes, imperfect perhaps. But I don't see anything fundamentally wrong with the contract. At worst, perhaps the method should have been named "AllLines" instead. The author could even have provided an additional "RemainingLines".

I do agree that the proposed fully-encapsulated version is much better, and that by hiding the stream and the reader altogether, it fully avoids interference and strange side-effects from the client code, which is a good thing. But coding isn't black and white, and I think there's room for imperfect implementations, when used appropriately.

re: High maintenance

Brandon Bloom — Tue, 09 Sep 2008 03:47:18 GMT

If you take a file name instead of an open file, your contract now includes a significant number of IO and security exceptions which could be raised...

re: High maintenance

Jonathan Pryor — Tue, 09 Sep 2008 05:50:35 GMT

And as an added bonus, the FileUtilities.Lines(string) version is harder to unit test, as it requires that a well-known file exist in a well-known location.

The .Lines(StreamReader) suffers from the same problem.

A .Lines(TextReader) version is quite easy to unit test, as you can pass it a StringReader to verify that it behaves the way you think it behaves (as long as StringReader and StreamReader follow the TextReader contract, which they should do...).

re: High maintenance

Ollie Riches — Tue, 09 Sep 2008 12:26:45 GMT

Another example of how not to use extension methods may be?

As for comments about Eric's implmentation taking a filename (path) and not a stream based reader - Eric's version encapsulates the file manipulation completely and abstracts the caller away from knowing how the file is being manipulated.

Also I don't see any issue with unit testing this either...

re: High maintenance

Senthil Kumar — Tue, 09 Sep 2008 13:06:35 GMT

There's another reason why the original code did a seek to 0. If it didn't, then the following piece of code would have printed false.

var lines = someStreamReader.Lines();

Console.WriteLine(lines.First() == lines.First())

All constructed enumerators would have referenced the same stream, so advancing one would have advanced all of them.

Eric's implementation avoids the problem by constructing a new StreamReader inside the method.

re: High maintenance

rbirkby — Tue, 09 Sep 2008 14:04:17 GMT

> " No one should be messing with that stream but the reader."

Or to put it another way - the "Inappropriate intimacy" Code Smell.

http://en.wikipedia.org/wiki/Code_smell

re: High maintenance

stefan.wenig — Tue, 09 Sep 2008 16:50:01 GMT

Eric,

you've just made a great case for generators in lambda expressions!

public static IEnumerable<string> Lines (this StreamReader reader)

{

if (reader == null)

throw new ArgumentNullException ("reader");

return new EnumerableWrapper<string> (delegate

{

for (; ; )

{

string line = reader.ReadLine ();

if (line == null)

yield break;

yield return line;

}

});

}

Wouldn't it be great if that could compile? (The EnumerableWrapper class would just implement IEnumerable<T> and IEnumerable, and delegate both to the Func<IEnumerable<T>> it receives. Anonymous classes would be another nice thing in this particular situation, but live as we know it doesn't quite end without them.)

The problem is that argument checking in a generator is a quite common case. What's your answer for that? Don't check those arguments? Manually build a closure class? Create psychic debugging situations?

I realize this is not quite simple, but still - it would be great, not?

re: High maintenance

Eric Lippert — Tue, 09 Sep 2008 18:00:39 GMT

Indeed, I would love to have anonymous iterators.

re: High maintenance

russellh — Tue, 09 Sep 2008 18:34:28 GMT

Maybe I'm very old school C, but what is so bad about this line?

while ((line = reader.ReadLine()) != null)

It just reads a line from the stream into line and checks for end of stream. Seems obvious to me.

re: High maintenance

Eric Lippert — Tue, 09 Sep 2008 18:44:45 GMT

First off, that line of code:

* calls ReadLine

* assigns to line

* checks the value assigned to see if it is null

* branches

four things is rather a lot for one line of code to be doing.

Second, there are five logical conditions that one might want to put a breakpoint immediately before:

* entering the loop

* reading the line

* testing the value

* finishing the iteration

* yielding the next value

In my version there are five different places to put breakpoints, one for each of these. In the original version, there are not.

Third, sure, any experienced C programmer can easily tell what this does, because it uses a C-style idiom. Why would you use a C-style idiom in C#? Use C# idioms in C#.

Fourth, just because you CAN write expressions that are terse doesn't mean that there is any virtue to them.

re: High maintenance

peted — Tue, 09 Sep 2008 20:17:10 GMT

"Indeed, I would love to have anonymous iterators."

<drool>

Me too! Me too! :)

re: High maintenance

Brian O — Tue, 09 Sep 2008 22:09:18 GMT

Nice post, Eric.

What do you think about adding the below check after the null argument test in Line().

if (!File.Exists(filename))

{

throw new FileNotFoundException("File does not exists", filename);

}

Pros: Exception is thrown closer to the error

Cons: Localization requirment if the constructor(string message, string filename) is used.

(side note: It would be nice if the FileNotFoundException constructor accepted a file path as the only argument, like the ArgumentNullException type. This would make a little nicer error message without having a localization burden.)

re: High maintenance

Bahador — Wed, 10 Sep 2008 08:59:43 GMT

Suppose the actual iteration of Lines() spans over a large period of time, and we don't want to maintain a lock on the file in the whole process.

Will you consider the method's contract clear if it was implemented the following way.

Specifically, is it better to writing the method this way, or we must give the caller the burden of first iterating over all the lines and cache them to use later?

public static class FileUtilities

{

public static IEnumerable<string> Lines(string filename)

{

if (filename == null)

throw new ArgumentNullException("filename");

Debug.Assert(filename != null);

List<string> s = new List<string>();

using (var reader = new StreamReader(filename))

{

while (true)

{

string line = reader.ReadLine();

if (line == null)

break;

s.Add(line);

}

return s;

}

re: High maintenance

[ICR] — Wed, 10 Sep 2008 11:37:45 GMT

I think by virtue of being an extension method the original has no obligation to clean up. I wouldn't expect a call to theStream.Method() to dispose of the stream. Of course that doesn't discount the issue of altering the stream, but without that I think the contract is then perfectly clear.

(For a precedence see ReadToEnd)

Though I would agree about not being too generic from the beginning.

re: High maintenance

Sebastien Lorion — Wed, 10 Sep 2008 22:57:24 GMT

I am surprised no one commented on the name of the method. "Lines" ... lines what? That tells me nothing about what the method does, I can only guess it by looking at its signature. I am a big proponent of method names being verbs and class names being nouns.

I also agree with some others that the method should work on TextReader. For me, the version using filename is just icing on the cake as it is probably the most common operation. Anyway, it all depends on the context where this class is used.

"[...] you have all the design, implementation and testing burden of ensuring that your system works with ANYTHING that can be a TextReader [...]"

Can you elaborate on that? As long as implementations of a TextReader respect its contract, I don't understand why you would impose on yourself such a burden, so I am curious to know your reasons for saying that.

What's wrong with this code, part II

Steve Strong's Blog — Thu, 11 Sep 2008 12:51:36 GMT

What's wrong with this code, part II

re: High maintenance

Sebastien Lorion — Fri, 12 Sep 2008 00:22:56 GMT

About the "while ((line = reader.ReadLine()) != null)" line, we would not need such a hack or the awkward code you posted if the method was better designed, for example:

bool ReadLine(out string line)

which gives

string line;

while (reader.ReadLine(out line))

{

yield return line;

}

re: High maintenance

Brennan — Sat, 13 Sep 2008 00:39:24 GMT

I disagree with the "ownership" idea in this case and in many Stream scenarios similar to this. BinaryReader "correctly" takes ownership of the stream and closes the stream when you're done with the BinaryReader. But sometimes you just need BinaryReader functionality for a subset of the stream. If that's you're secenario you're out of luck--you have to reimplement BinaryReader! That's the greater of the evils.

re: High maintenance

Eric Lippert — Sat, 13 Sep 2008 01:28:19 GMT

So Brennan, your suggestion is that the frameworks designers ought to make the 99% likely common case difficult and bug-prone so that the 1% rare case works more easily?

An important principle of frameworks design is that the people doing weird stuff should be the ones writing the goofy code. The people doing normal stuff should be given implementations that are not bug-prone.

That said, I also disagree completely with your claim that the only alternative is to reimplement the reader. Were I faced with such a 1% scenario, I'd just implement a thin "no dispose stream" that wraps the underlying stream, but does not pass along the call to dispose. You want to make a binary reader that doesn't dispose the stream, you just wrap the stream in your 'no dispose wrapper' and hand that thing to the reader. When the reader disposes the stream, that's a no-op and the underlying stream lives on. That seems a lot easier than re-implementing the reader.

Weekly Web Nuggets #29

Code Monkey Labs — Mon, 15 Sep 2008 06:03:16 GMT

General Comparing .NET IoC Frameworks Part 1 : Andrey Shchekin takes a look at 6 of the most popular IoC frameworks available for .NET. Comparing .NET IoC Frameworks Part 2 : The continuation of Andrey Shchekin's IoC shootout. High Maintenance Code :

re: High maintenance

Greg — Thu, 18 Sep 2008 02:25:42 GMT

I'd discourage this type of code in production systems for maintainablity reasons as it fails the Monday morning, I did not get any sleep the night before and my brain is dead, code understandable test.

It hides its purpose which is to facilitate forward movement line by line through a text file.

Cute code like this is OK when used one or a few times in an application, but damages the maintainability of a large application with many hundred of different examples of cute tricky code.

re: High maintenance

Chuck Enders — Tue, 23 Sep 2008 01:44:34 GMT

Excellent discussion.

Please don't let the pointy-haired boss have the last word.

High maintenance code

DotNetKicks.com — Tue, 23 Sep 2008 07:20:45 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: High maintenance

stefan.wenig — Wed, 24 Sep 2008 11:22:48 GMT

Somehow my comment was lost. I like your solution so much that I documented it as a pattern, see community content at http://msdn.microsoft.com/en-us/library/65zzykke.aspx

cheers

re: High maintenance

Eric Lippert — Wed, 24 Sep 2008 17:44:45 GMT

Nice, thanks!

re: High maintenance

Richard — Tue, 30 Sep 2008 17:25:53 GMT

A StreamReader / StreamWriter taking ownership of a Stream just seems wrong. Methods and classes should not be responsible for cleaning up resources that they didn't create, unless this is clearly documented and obvious.

For example, the following looks like it should work, but fails unexpectedly with an ObjectDisposedException on the call to Seek:

using (var s = new MemoryStream(capacity))

{

using (var writer = new StreamWriter(s))

{

Render(writer);

}

s.Seek(0L, SeekOrigin.Begin);

using (var reader = new StreamReader(s))

{

return reader.ReadToEnd();

}

Since the caller created the Stream, it should be the caller's responsibility to close it.

Blog Carnival #6

IHateSpaghetti {code} — Wed, 01 Oct 2008 00:12:43 GMT

In this carnival there're a lot of software design/patterns and frameworks a bit of SOA, UML, DSL

re: High maintenance

Stephen — Tue, 11 Nov 2008 19:37:36 GMT

I know this is an old topic but I'm really confused regarding why a reader or writer should close the stream itself..

If I had to create a reader or writer in a way that the reader had to aquire the stream itself, then I would expect the reader to handle cleaning it.. but personally I don't see the readers job as aquiring the stream.. I see that as maybe helper methods.

It makes completely sense that the solution should be

using(var stream = .. aquire stream ..)

{

using(var reader = new StreamReader(stream))

{

.. do stuff..

}

stream.Close();

}

I certainly wouldn't be expecting the stream to close the stream.. the reader didn't get the stream, I gave it the stream, so I will dispose the stream as well, thats my contract in the code...

It seems to go against seperation of concerns, reader becomes somewhat of a 'jack of all trades'.. hey guy don't worry - I'll close the stream when you're done, because thats generally what you want no?

The code I wrote makes much more sense.. whos doing what.. I'm getting a stream.. I'm reading over the stream.. I'm closing/disposing the stream..

I agree changing .net now is impossible, the amount of code written thats now expecting this behavior.. but I'd go as far as classifying this in the relms of the clr array.. oh did you guys know i do unsafe invariance as covariance as well? (echoing off)

nooooooooooooo!

A nasality talisman for the sultana analyst

Fabulous Adventures In Coding — Thu, 05 Feb 2009 00:52:51 GMT

The other day my charming wife Leah and I were playing Scrabble Brand Crossword Game (a registered trademark

re: High maintenance

Jacco — Wed, 11 Mar 2009 00:17:08 GMT

Hi Eric,

Sorry to respond to such an old post. I was triggered to go here from your Scrabble post :-)

I am working on an extension library (nxl on codeplex) and am struggling with this one. I came up with the following code but am not sure if its very usable:

public static IEnumerable<string> StreamLines(Func<Stream> streamConstructor)
     {
       using (Stream stream = streamConstructor()) {
         using (var sr = new StreamReader(stream))
         {
           while (true)
           {
             string line = sr.ReadLine();
             if (line == null)
               yield break;
             yield return line;
           }
         }
       }
     }

The ownership issue is solved this way but usage is a bit clunky:

foreach (string line in StreamExtensions.StreamLines(() => File.Open("C:\test.txt", FileMode.OpenRead)))

It not even an extension any more :S

Does it make sense to go this road?

Regards, Jacco

Ah, you are using lambdas to implement lazy evaluation of the stream opening. Is that so that if someone takes out an enumerator and then sits on it without moving it, the file open doesn't happen until the first line is requested? That's pretty clever. A bit clunky, and perhaps a bit TOO clever, but neat. I like it from the point of view of a mechanism that solves this problem.

However, from a usability standpoint, it's pretty taxing. If the method "StreamLines" is intended to take a stream and return some lines then it should take a stream and return some lines. Your "lazy evaluation" feature imposes a "tax" on ALL users of this method, not just the users who want to take advantage of the feature.

What I might do in this case is write two extension methods, one that takes a stream, one that takes a func<stream>. Then you can decide which one you want to use and don't have to pay a tax if you don't want laziness.

Another way to attack the problem would be to make a new subtype of Stream called LazyStream. A LazyStream takes your Func<Stream>, and then forwards all calls to the lazy evaluated stream when asked. The user can then create a LazyStream if they want to have a stream that isn't opened until its needed.

-- Eric