Does BufferedReader.ready() method ensure that readLine() method does not return NULL?

Question

I have such code to read a text file using BufferedReader:

BufferedReader reader=null;
    try {
        reader = new BufferedReader(new FileRea         


        

Answer 1

Look at the API for ready.

What you're doing is wrong. ready() only tells you if the stream is readable and valid. Read the comment under return on that link as well.

What you want to do is:

String thisLine;

//Loop across the arguments
for (int i=0; i < args.length; i++) {

  //Open the file for reading
  try {
    BufferedReader br = new BufferedReader(new FileReader(args[i]));
    while ((thisLine = br.readLine()) != null) { // while loop begins here
      System.out.println(thisLine);
    } // end while 
  } // end try
  catch (IOException e) {
    System.err.println("Error: " + e);
  }
} // end for

Answer 2

The ready method tells us if the Stream is ready to be read.

Imagine your stream is reading data from a network socket. In this case, the stream may not have ended, because the socket has not been closed, yet it may not be ready for the next chunk of data, because the other end of the socket has not pushed any more data.

In the above scenario, we cannot read any more data until the remote end pushes it, so we have to wait for the data to become available, or for the socket to be closed. The ready() method tells us when the data is available.

Answer 3

The Reader.ready() and InputStream.available() rarely work as you might like, and I don't suggest you use them. To read a file you should use

String line;
while ((line = reader.readLine()) != null)
    System.out.println("<"+line+">");

Answer 4

Here's what the Javadocs have to say:

Tells whether this stream is ready to be read. A buffered character stream is ready if the buffer is not empty, or if the underlying character stream is ready.

So a BufferedReader is considered ready simply if the underlying stream is also ready. Since BufferedReader is a wrapper, this underlying stream could be any Reader implementation; hence the semantics of ready() are those declared on the interface:

Returns true if the next read() is guaranteed not to block for input, false otherwise. Note that returning false does not guarantee that the next read will block.

So you only really get timing guarantees, i.e. that read() will not block. The result of calling ready() tells you absolutely nothing about the content you'll get back from a read() call, and so cannot be used to elide a null check.