Why Java StringReader throws IOException?

Question

Today I was working with Java class StringReader and I found it very annoying that it throws IOException on read method. I know that it extends Reader class in which method read throw IOException but I think that it is not needed for StringReader. This class doesn't use any external resources that might cause errors.

After short investigation I found out that StringReader#read throws IOException if string which this class reads is null but de facto this can't happen because if we would try to pass null to StringReader constructor it throws NPE.

What do you think about it, is it good practice to always throw the same exceptions as super class?

---

Edit: As noted by U Mad Reader is a class not interface.

Answer 1

Please have a look at StringReader#read().

Look at the source code of StringReader#read() method. It calls ensureOpen() method that is actually throwing IOException because ensureOpen() checks to make sure that the stream has not been closed.

If reader is closed and then after read() is called again then what will happen?

Source Code directly from above link (Look at the comments):

/**
 * Reads a single character.
 *
 * @return     The character read, or -1 if the end of the stream has been
 *             reached
 *
 * @exception  IOException  If an I/O error occurs
 */
public int read() throws IOException {
    synchronized (lock) {
        ensureOpen();
        if (next >= length)
            return -1;
        return str.charAt(next++);
    }
}

/** Check to make sure that the stream has not been closed */
private void ensureOpen() throws IOException {
    if (str == null)
        throw new IOException("Stream closed");
}

/**
 * Closes the stream and releases any system resources associated with
 * it. Once the stream has been closed, further read(),
 * ready(), mark(), or reset() invocations will throw an IOException.
 * Closing a previously closed stream has no effect.
 */
public void close() {
    str = null;
}

Answer 2

I think it is not a good practice to throw the same exceptions as the super class or interface definition if your implementation ensures it will never happen. I would always reduce a signature to the bare minimum required.

The IOException is required for all the implementations imaginable, including file sources and streams and sockets etc. Without, such implementations could not notify their errors as a checked exception. But if an implementation has no need to throw a checked exception (which is often annoying for the calling code) removing it from the implementing class does no harm, but removes some burden.

UPDATE:

I have found the reason why the method read() must throw an IOException: because of the contract defined for the close() method. From the JavaDoc:

Closes the stream and releases any system resources associated with it. Once the stream has been closed, further read(), ready(), mark(), or reset() invocations will throw an IOException. Closing a previously closed stream has no effect.

Answer 3

When you implement a method of interface in your class it is not required to provide same exception arguments. Same case apply when you override declaration of method from super class.

public class MyReader implements Readable {

    @Override
    public int read(CharBuffer cb)  {
        return 0;
    }

}

But then you are not using the interface in proper way. And you do not benefit from this in case when you are coding to interface.

Readable readable = new MyReader();

        try {
            readable.read(null);
        } catch (IOException e) {
            e.printStackTrace();
        }

Even in the MyReader do not expose the IOException you still have to use try block. So in case you do not throw exception of the method you implement may point that you missed something in your implementation of that method. So IMHO it is not a good practice do to so.

The reason why StringBuilder throws IOException is not that it implement the interface Readable. The reason of that is validation of the input in method ensureOpen() that throw an IOException when input is null. Then input can be null when method close() is called or you pass null to constructor. As method close is abstract it must have some effect in the child class. The expected is that after you call close you can no longer read from it and you will get IOException.

This is perfect, clean and solid implementation that take into account all potential use cases.