CODEWITHSUNDEEP
javafileio
smerlin
smerlin

Reputation: 6566

FileOutputStream: Stream closed

Solved, In short: the problem was that I wrote to an already closed FileOutputStream

I noticed some strange semantics using the FileOutputStream class.

If I create a FileOutputStream using this code:

try {
    File astDumpFile = new File(dumpASTPath);
    if(!astDumpFile.exists()) {
        astDumpFile.createNewFile();
    }
    astDumpStream = new FileOutputStream(dumpASTPath);
} catch( IOException e ) {
    dumpAST = false;
    //throw new IOException("Failed to open file for dumping AST: " + dumpASTPath);
    System.out.println("Failed to open file for dumping AST: " + dumpASTPath);
}

at the beginning of the program (astDumpStream is a member variable). Then if I later (~3 seconds later) write string data to the file, i get an IOException: stream closed:

try {
    String dotGraph = gpvisitor.getDotGraph();
    astDumpStream.write(dotGraph.getBytes("UTF8"));
    astDumpStream.flush();
    astDumpStream.close();
} catch( IOException e ) {
    System.out.println("Failed to dump AST to file: " + e.getMessage());
    e.printStackTrace();
}

However if I copy the excact code which I use to create the FileOutputStream to directly before writing to it, it works as expected.

Now I wonder why do I get that exception if I create that object earlier, but not if I create it directly before I use it.

EDIT: The exception:

java.io.IOException: Stream Closed
    at java.io.FileOutputStream.writeBytes(Native Method)
    at java.io.FileOutputStream.write(FileOutputStream.java:305)
    at MyClass.function(MyClass.java:208)

I just noticed, that even though I get an exception, still some data was written to the file. Interrestingly the first line is written completely, then all following lines except the last line are missing. If I replace the written String dotGraph with something shorter everything is written correctly, however I still get that exception.

EDIT: Environment Information:

[~]> lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux testing (wheezy)
Release:        testing
Codename:       wheezy
[~]> java -version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)

Upvotes: 0

Views: 10435

Answers (3)

Yogesh Devi
Yogesh Devi

Reputation: 689

To Second Tedd - in case you happen to use a nested try with resource block and using stream outside tryblock - you could run in this situation as well because once the control comes out of nested try with resource block the stream will be closed.

Upvotes: 0

Brendan Long
Brendan Long

Reputation: 54302

The only way this can happen if is the close() function gets called more than once. My guess is that for some reason, the second block of code is being called more than once.

To prevent indentation errors, there are two good pieces of advice I've received:

  • Always indent consistently. Preferably use a tool that does this for you (like Eclipse).
  • Always use curly braces, even if you don't think you need them. This helps prevent quite a few minor bugs that take forever to find, so the extra half-second it takes to type each one is more than made up by the hours you don't spend looking for these bugs.

Upvotes: 1

Ted Hopp
Ted Hopp

Reputation: 234847

The only reason to get an IOException complaining that the stream is closed is because the stream was closed. You'll have to trace through your code to find out where that's happening. Some not-so-obvious places include calls into other methods and finally blocks of try statements. Another thing to look for is reassignment of the variable astDumpStream to a different stream (that was closed before the IOException was raised—possibly even before the first assignment to astDumpStream).

The time doesn't seem relevant unless you have a separate thread that might close the stream after a delay.

Upvotes: 5

Related Questions