This week's book giveaway is in the Agile and Other Processes forum. We're giving away four copies of Darcy DeClute's Scrum Master Certification Guide: The Definitive Resource for Passing the CSM and PSM Exams and have Darcy DeClute on-line! See this thread for details.
Long story short I was given a mundane task at work that a simple program could do much quicker for me. I've got it mostly done, I'm able to read from teh file just fine but I'm having trouble writing to the various files I want to...I think it has to do with the creation of the PrintWriter and the method I'm using. Anyone see anything below:
I know my logic is correct because I tested with System.out first.
WOOT! That worked. Thanks Edwin. Now why is it important to use "flush"? As easy as this was it's probably pretty clear I'm missing a few of the key details about the intricacies of I/O....and some may say Java. But I'm still working on it. It's been a rough year so far.
It's not important to call flush() before closing -- it's important to call close(), which you're not doing. Calling "flush()" mitigates the problem, but the right way to do things is to close a file when you're through with it.
Many output streams buffer writes to improve performance. Rather than sending each byte to its destination as it's written, the bytes are accumulated in a memory buffer ranging in size from several bytes to several thousand bytes. When the buffer fills up, all the data is sent at once. The flush() method forces the data to be written whether or not the buffer is full [...].
If you only use a stream for a short time, you don't need to flush it explicitly. It should be flushed when the stream is closed. This should happen when the program exits or when you explicitly invoke the close() method [...].
You only need to flush an output stream explicitly if you want to make sure data is sent before you're through with the stream. For example, a program that sends a burst of data across the network periodically should flush after each burst of data is written to the stream [...].
Flushing is often important when you're trying to debug a crashing program. All streams flush automatically when their buffers fill up, and all streams should be flushed when a program terminates normally. If a program terminates abnormally, however, buffers may not get flushed. In this case, unless there is an explicit call to flush() after each write, you can't be sure the data that appears in the output indicates the point at which the program crashed. In fact, the program may have continued to run for some time past that point before it crashed.
System.out, System.err, and some (but not all) other print streams automatically flush after each call to println() and after each time a new line character ('\n') appears in the string being written. Whether auto-flushing is enabled can be set in the PrintStream constructor.
[ May 10, 2006: Message edited by: Edwin Dalorzo ]
Originally posted by Ernest Friedman-Hill: It's not important to call flush() before closing -- it's important to call close(), which you're not doing. Calling "flush()" mitigates the problem, but the right way to do things is to close a file when you're through with it.
so instead of changing the constructor it would be a better idea to close all the output streams just before the end of the try block?
hey that worked too. I need to read the I/O chapter from the book (one of many) that I have so this makes sense.
Originally posted by Edwin Dalorzo: From Java IO by Elliotte Rusty Harold.
Be careful. For the PrintWriters in use here, it's not true that printing a '\n' calls flush() in auto-flush mode; it was (is) true for PrintStream, however.
It's also not true that the chains of open PrintWriter/BufferedWriter/FileWriters will automatically be flushed on program exit. The underlying file stream will be closed and the OS buffer flushed, but the BufferedWriters are going to be holding some data, and that will be lost unless you flush() or close() the PrintWriters. Nothing is going to automatically close() or flush() them for you.