Using The Streamwriter Object Why use the StreamWriter and how to use it correctly?

[k_nitin_r 8]

If you have worked with the StreamWriter object in .NET, you probably know how much of a pain it is when getting started. The StreamWriter is a buffer writer and it was built to improve the performance of your application, but if not used corrently, it can lead to data loss (and I am still trying to figure out where in the StreamWriter-sprinkled code do I have something that isn't writing to a file I'm expecting output in).Let's suppose that you have a FileStream object, perhaps created through File.OpenWrite or maybe even the FileStream constructor. When you call the constructor of the StreamWriter class, you would pass in the FileStream object like this: "New StreamWriter(ObjFileStream)". Getting an instance of the StreamWriter class is as simple as that - you don't have to tell the StreamWriter what kind of stream it is - Is it a file? Is it a network stream? Is it a line printer stream... (Reminds me of - is it a bird, is it a plane, no, it's superman!)Writing with the stream writer object is as simple as writing to Console because you have the Write and WriteLine methods that the Console object has and the Console object is one of the first things you work with when developing for the command line, so I'm assuming that's something we all know like the back of our hands. To write using the stream writer, we would have a call that looks like this: "StrWrite.WriteLine(MyStringHere)". Just as with the Console.WriteLine class, you would expect the text to appear in the file, right?Well, apparently it isn't so. My little console application simply open a file stream, creates a streamwriter object, and writes using the streamwriter class, then closes the file. When I close the application and actually look at the file, it is zero bytes in length. That's right, I've got nothing there, zilch, nada, you get my point! So, I look back at the code and try to perform a not-so-forensic analysis of what may have gone wrong. Considering the possibility of a buffer in the FileStream, I add in a Flush call to the FileStream object and run the application again, but there's absolutely no difference in the output of the application, so I decide that I'm barking up the wrong tree - I've flushed the filestream object before closing it and I did make sure that the FileStream object was appropriately closed with the call to the Close method so there's absolutely nothing wrong in there. I then turn my attention to the StreamWriter object, which seems to be the prime suspect in this case, and boy, was it really really guilty! Behind the scenes, when nobody is around, and when there are no eyes or ears around to figure out what's really going on, the StreamWriter object takes your string and goes off to sleep. Yes, that's write - it does not write to the stream. Imagine that, a lazy bugger slouching off while on-duty! So, the sloth (read: instance) of a StreamWriter class just leaves your string there on the work table, untouched, till it actually thinks that there's so much on the table that there's no space left there at all and it just has to go on there and get some work done lest the table itself collapses under the weight. In other words, the StreamWriter object maintains a buffer so that it does not have to write to the stream each time you make a call to the Write or the WriteLine method. The advantage of this is the application does not have to wait on the stream to finish writing each time it makes a call to the Write or the WriteLine method and therefore the application feels quicker. Why is it quicker? Think about your recent shopping trip to the grocery store. When you did have to line-up in a queue to get a bottle of Coke (sorry, Pepsi, they've got a shorter name and so its easier to type), you would have to wait in the queue for about 2 minutes, pay for the Coke, and head out... just then, you figure out that the Coke bottle needs a bottle opener so you head back into the store, get the bottle opener, wait in the queue for another 2 minutes, pay for the bottle opener, and you head out. See the problem there? Because you had to get into the queue twice, you had to waste a good 4 minutes of your time that would otherwise have been spent watching the game on television (or something equally useless and unproductive), but the point here is that it's simply inefficient. Instead, if you got both the Coke and the bottle opener the first time, you would have spent only 2 minutes in the queue. Anyway, so that's exactly what the StreamWriter object does.Okay, now that we know why the StreamWriter is a celebrity in these parts, how do we get it to actually write the output to our file? Simple - we call the StreamWriter object's Flush method. That's write, just as the FileStream object has a Flush method to call, the StreamWriter has a Flush method too! The Flush tells StreamWriter to get off it's lazy bu*t and get the job done before it has to get shipped off to someplace else (shipping off the work product, not the StreamWriter object!)Anyway, having done all that, I now have my application writing output to the file just as I expect it to and I hope we've all learned a lesson out of all of this - don't trust that sloth of a StreamWriter to ever do it's job. You're supposed to get back in there and Flush out all of the data in the end!