I'm writing code to read a file and process it and I'm splitting logic into many small methods. So I have a method to read the file and return BufferedReader and another one to do logic with the returned BufferedReader object. But when I try to read lines from the BufferedReader object in the second method it gives me [java.io.IOException: Stream Closed].
The method I used to read the file and return BufferedReader
private static BufferedReader readFile(String file) {
try (FileInputStream fileInputStream = new FileInputStream(file)) {
BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(fileInputStream));
System.out.println(bufferedReader.readLine()); // this line is working successfully
return bufferedReader;
} catch (FileNotFoundException fileNotFoundException) {
fileNotFoundException.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
Any idea why the happens and how to solve it ?
You are using try-with-resources:
try (FileInputStream fileInputStream = new FileInputStream(file)) {
This line is creating a FileInputStream which can be used inside your try block. As soon as you leave your try block, the close() method will be called onto the stream. So if you return the stream or its BufferedReader, the stream will already be closed. You should not use try-with-resources or even better, return whatever you need from the stream instead of the stream itself.
Obviously, the problem here lies in the use of try-with-resources, and AutoCloseable interface. However, i would like to point out that the way you read the file is the "old fashioned" way. We now have the Files, Paths, and Stream classes to facilitate reading of files. this uses java NIO, returns a Stream and is better overall:
Files.lines(Paths.get(pathToFile))
additionally, nothing has to be closed here
Related
First of all, yes, try-with-resource fixes any of these questions... but I can't see how this exactly works without it.
Let's look at this code from the java documentation as an example, which can be found here:
static String readFirstLineFromFileWithFinallyBlock(String path)
throws IOException {
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
if (br != null) br.close();
}
}
Now, the resource is released on br.close() if it was acquired. However,
What happens if new FileReader(path) succeeds and then new BufferedReader(...) throws an exception?
How does java guarantee that the FileReader is closed?
Is it guaranteed that creating a BufferedReader on an already opened FileReader will always succeed? If so, why is that method declared as throwing an IOException?
Or should we instead be writing the following to make sure that situation doesn't happen?
static String readFirstLineFromFileWithFinallyBlock(String path)
throws IOException {
FileReader fr;
try {
FileReader fr = new FileReader(path);
BufferedReader br;
try {
BufferedReader br = new BufferedReader(fr);
return br.readLine();
} finally {
if (br != null) br.close();
}
finally {
// Implements closeable, so it is ok if we call it twice.
if (fr != null) fr.close();
}
}
Of course, using try-with-resources, this nested mess disappears nonetheless, since we can declare multiple resources in the same statement. But I always see myself writing try-with-resources as a way to avoid thinking at all about exactly this situation, and trying to find a solution online I really couldn't.
Any help would be appreciated, thanks!
The tutorials are often out of date or don't describe good practice.
If we look at the first piece of code you quoted, br can never be null. The if ( ) can be removed. This was probably caused by previous code by previous code mixing to finally with a catch. If a try statement has both finally and a catch it is probably wrong and almost certainly doing something ill advised. Typically you'd see a null dance going on and at least one obvious bug.
The received wisdom on this issue is that BufferedReader will only fail if something has gone horribly wrong with your entire process. Perhaps out of memory or the stack have overflowed. If you get those sorts of exceptions you probably want to bail out of altogether.
The pedantic way of writing the code without try-with-resource is:
FileReader fr = new FileReader(path);
try {
BufferedReader br = new BufferedReader(fr);
return br.readLine();
} finally {
fr.close();
}
However, in some case you may get this wrong. Considered BufferWriter. You've forgotten to flush that, haven't you? I mean, I would. If you closed that in a finally, it wouldn't have been a problem. Also some decorators are resources themselves. For instance, they may have a native implementation that uses non-garbage collected memory. That isn't necessarily documented.
Closing both resource and decorator isn't difficult, but does kind of head towards the right without try with resource.
// (Using same example even though it doesn't matter here - imaging a Writer)
FileReader fr = new FileReader(path);
try {
BufferedReader br = new BufferedReader(fr);
try {
return br.readLine();
} finally {
br.close();
}
} finally {
fr.close();
}
Look in java source code at implementation of close() for BufferedReader.
* #see FileReader
* #see InputStreamReader
* #see java.nio.file.Files#newBufferedReader
*
* #author Mark Reinhold
* #since 1.1
*/
public class BufferedReader extends Reader {
private Reader in;
...
public void close() throws IOException {
synchronized (lock) {
if (in == null)
return;
try {
in.close();
} finally {
in = null;
cb = null;
}
}
}
...
/**
* Creates a buffering character-input stream that uses an input buffer of
* the specified size.
*
* #param in A Reader
* #param sz Input-buffer size
*
* #exception IllegalArgumentException If {#code sz <= 0}
*/
public BufferedReader(Reader in, int sz) {
super(in);
if (sz <= 0)
throw new IllegalArgumentException("Buffer size <= 0");
this.in = in;
cb = new char[sz];
nextChar = nChars = 0;
}
/**
* Creates a buffering character-input stream that uses a default-sized
* input buffer.
*
* #param in A Reader
*/
public BufferedReader(Reader in) {
this(in, defaultCharBufferSize);
}
so close() is taken care of Reader (FileReader here) and set it to null.
Simply BufferedReader br = new BufferedReader(new FileReader(path)) is fine
Does nested resource acquisition require special handling in Java?
here: NO
What happens if new FileReader(path) succeeds and then new BufferedReader(...) throws an exception?
The BufferedReader constructor doesn't throw exceptions. Particularly, it doesn't involve any filesystem operations, so it doesn't throw IOException.
How does java guarantee that the FileReader is closed?
The BufferedReader's close method closes the underlying FileReader.
Is it guaranteed that creating a BufferedReader on an already opened FileReader will always succeed? If so, why is that method declared as throwing an IOException?
You're focusing on the wrong thing. readFirstLineFromFileWithFinallyBlock is marked with throws IOException because every method or constructor invoked besides the BufferedReader constructor can throw IOException. readline, close, and the FileReader constructor can all throw.
If both the FileReader and BufferedReader constructors could fail, and if both objects needed to be closed separately, then you would need two trys.
You can use try with resources instead of releasing resources individually. Please look the below code.
try(BufferedReader bufferedReader = new BufferedReader(new FileReader(""))) {
}catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
I have a method that receives a string with a filepath, and i have created all the code for reading the file, with the try a catch blocks, somthing very simple like this:
private static String readLineFormFile(String filename){
File filepath= new File(filename);
BufferedReader reader = null;
String line =null;
try{
reader = new BufferedReader(new FileReader(filepath));
line=reader.readLine();
}
catch (FileNotFoundException fe1){
System.out.println(filename+" file Not Found");
}
catch (IOException ie1) {
System.out.println("Error Reading File "+filename);
}
finally{
try{
reader.close();
}catch(IOException ie2){
System.out.println("Error closing file "+filename);
}
}
return line;
}
Now if I call this method on a file 2 times, will the buffereader still know the line I was after I close it for the first time?
will the buffereader still [k]now the line i was after i close it for the first time?
No. You will be reading from the beginning of the file each time.
No.
Each time you run the method, a new BufferedReader object is created. When the method ends, the object is destroyed, and a new one is created the next time you run the method.
The information about where you're up to in the reading is stored in the BufferedReader object, and is not shared by all such objects.
What object instance would that be? The BufferedReader instance is created twice; once for each call, using the new keyword on the constructor. reader is a local variable that goes out of scope when the method is exited.
I've got the following piece of code:
public ArrayList<Crime> loadCrimes() throws IOException, JSONException {
ArrayList<Crime> crimes = new ArrayList<Crime>();
BufferedReader reader = null;
try {
// Open and read the file into a StringBuilder
InputStream in = mContext.openFileInput(mFilename);
//what if an exception gets thrown in the line below?
reader = new BufferedReader(new InputStreamReader(in));
StringBuilder jsonString = new StringBuilder();
String line = null;
while ((line = reader.readLine()) != null) {
// Line breaks are omitted and irrelevant
jsonString.append(line);
}
// Parse the JSON using JSONTokener
JSONArray array = (JSONArray) new JSONTokener(jsonString.toString()).nextValue();
// Build the array of crimes from JSONObjects
for (int i = 0; i < array.length(); i++) {
crimes.add(new Crime(array.getJSONObject(i)));
}
} catch (FileNotFoundException e) {
// Ignore this one; it happens when starting fresh
} finally {
if (reader != null)
reader.close();
}
return crimes;
}
First, I wondered why we call .close() just on the BufferedReader object and not on the InputStream and InputStreamReader objects. I checked the official Oracle documentation and skimmed through a couple of questions in stackoverflow and according to what I've read BufferedReader.close() takes care of releasing the resources acquired by InputStreamReader and InputStream, so I don't have to call .close() on them.
Is this correct?
Secondly, I thought what would happen if an exception got thrown after creating the InputStream object and before creating the BufferedReader object. That is, either the InputStreamReader(InputStream in) constructor or BufferedReader(Reader in) constructor throws an exception. In that case we have acquired a file resource with InputStream but the BufferedReader object is still null, so in the finally block, the .close() method will not be invoked and the InputStream will not release the resources it has acquired.
Then I read the Oracle documentation, and neither of those two constructors throw an exception according to it. So it's not possible for an exception to occur between those two lines, right?
My final question is "Does this piece of code make sure it releases all resources it acquires?"
First, I wondered why we call .close() just on the BufferedReader object and not on the InputStream and InputStreamReader objects. I checked the official Oracle documentation and skimmed through a couple of questions in stackoverflow and according to what I've read BufferedReader.close() takes care of releasing the resources acquired by InputStreamReader and InputStream, so I don't have to call .close() on them.
Is this correct?
Yes, it is.
My final question is "Does this piece of code make sure it releases all resources it acquires?"
Most probably, yes. Even if some odd exceptions occur when creating the InputStreamReader or the BufferedReader, after exiting the block where they're defined, before GC collects them, they will be automatically closed as well. Of course, it's usually not a good idea to count on the GC to cleanup for you so if you want to be 100% sure, you might want to do it yourself in the finally block.
Another easier way is to use a FileReader which will simplify the code by only using two objects:
BufferedReader reader = new BufferedReader(new FileReader(fileName));
(I am assuming you want to read from a file).
I am trying an example from
http://www.roseindia.net/java/beginners/java-read-file-line-by-line.shtml
in the example the BufferReader is not closed is that necessary to close the BufferReaderor not? Please explain.
FileInputStream fstream = new FileInputStream("textfile.txt");
BufferedReader br = new BufferedReader(new InputStreamReader(fstream));
String strLine;
//Read File Line By Line
while ((strLine = br.readLine()) != null) {
// Print the content on the console
System.out.println (strLine);
}
//Close the input stream
in.close();
Always close streams. It's a good habit which helps you to avoid some odd behaviour. Calling close() method also calls flush() so you don't have do this manually.
The best place where to close streams is probably in a finally block. If you have it like in your example and an exception occurs before the in.close() line, the stream won't be closed.
And if you have chained streams, you can only close the last one and all before it are closed too. This means br.close() in your example - not in.close();
Example
try {
// do something with streams
} catch (IOException e) {
// process exception - log, wrap into your runtime, whatever you want to...
} finally {
try {
stream.close();
} catch (IOException e) {
// error - log it at least
}
}
Alternatively you can use closeQuietly(java.io.InputStream) in Apache Commons library.
From the perspective of resource leak prevention, it is not strictly necessary to close a wrapper stream if you've also closed the stream that it wraps. However, closing the wrapped stream may result in stuff getting lost (specifically in the output case), so it is better to close (just) the wrapper, and rely on documented behavior that the closing the wrapper closes the wrapped stream too. (That is certainly true for the standard I/O wrapper classes!)
Like Peter Lawrey, I question the wisdom of relying on "Rose India" examples. For instance, this one has two more obvious mistakes in it that no half-decent Java programmer should make:
The stream is not closed in a finally block. If any exception is thrown between opening and closing, the in.close() statement won't be executed, and the application will leak an open file descriptor. Do that too often and your application will start throwing unexpected IOExceptions.
The DataInputStream in the chain serves no useful purpose. Instead, they should use fstream as the parameter for the InputStreamReader. Or better still, use FileReader.
Finally, here is a corrected version of the example:
BufferedReader br = new BufferedReader(new FileReader ("textfile.txt"));
try {
String line;
while ((line = br.readLine()) != null) {
// Print the content on the console
System.out.println(line);
}
} finally {
// Close the reader stack.
br.close();
}
or using Java 7's "try with resource":
try (BufferedReader br = new BufferedReader(new FileReader ("textfile.txt"))) {
String line;
while ((line = br.readLine()) != null) {
// Print the content on the console
System.out.println(line);
}
}
Since the underlying stream is closed, it is not absolutely necessary to close BufferedReader, even though it is a good practice to close ALL Closeables in reverse order (relative to the order they were opened in.)
I haven't written any Java in years and I went back to refresh my memory with a simple 'read-from-file' example. Here is my code..
import java.io.*;
public class filereading {
public static void main(String[] args) {
File file = new File("C:\\file.txt");
FileInputStream fs = null;
BufferedInputStream bs = null;
DataInputStream ds = null;
try
{
fs = new FileInputStream(file);
bs = new BufferedInputStream(bs);
ds = new DataInputStream(ds);
while(ds.available()!= 0)
{
String readLine = ds.readLine();
System.out.println(readLine);
}
ds.close();
bs.close();
fs.close();
}
catch(FileNotFoundException e)
{
e.printStackTrace();
}
catch(IOException e)
{
e.printStackTrace();
}
}
}
This compiles fine (although apparently ds.readLine() is deprected), but at runtime, this gives me
Exception in thread "main"
java.lang.NullPointerException at
java.io.FilterInputStream.available(Unknown
Source) at
filereading.main(filereading.java:21)
What gives?
You made a simple typo:
ds = new DataInputStream(ds);
should be
ds = new DataInputStream(bs);
Your code is initializing the DataInputStream with a null source, since ds hasn't been created yet.
Having said that, Jon Skeet's answer gives a better way to write a file-reading program (and you should always use Readers/Writers rather than Streams when dealing with text).
To read a text file, use BufferedReader - in this case, wrapped round an InputStreamReader, wrapped round a FileInputStream. (This allows you to set the encoding explicitly - which you should definitely do.) You should also close resources in finally blocks, of course.
You should then read lines until readLine() returns null, rather than relying on available() IMO. I suspect you'll find that readLine() was returning null for the last line in the file, even though available() returned 2 to indicate the final \r\n. Just a hunch though.
String line;
while ((line = reader.readLine()) != null)
{
System.out.println(line);
}