Find out whether an InputStream is closed

Question

Does Java have any reliable way of determining whether a java.io.InputStream is closed before I attempt to read from it?

My use case is that I have a method that takes an InputStream argument and reads from it. The method runs in its own thread, and I want to terminate the thread if the input stream is closed.

InputStream implements Closeable, which provides a close() method but apparently no way to query if the instance has already been closed.

Attempting to read from closed InputStream will throw an IOException, but that could have other causes, and there is nothing in the interface contract stating whether this condition is permanent or if, under some circumstances, there is a chance it will go away sometime.

Callers of my method can supply any subclass of InputStream they wish, so relying on specific subclass behavior is not an option.

Any other ideas?

Answer 1

No. There's no API for determining whether a stream has been closed.

Applications should be (and generally are) designed so it isn't necessary to track the state of a stream explicitly. Streams should be opened and reliably closed in an ARM block, and inside the block, it should be safe to assume that the stream is open. When an an ARM block is used idiomatically, it naturally scopes the reference to a stream so that no one can access it after it's closed.

There are a number of ways that streams can be logically "closed", and many stream implementations will not detect this until a read() call is made. For example, if a server closes a socket, the internal state of the socket object in your client is unlikely to asynchronously reflect this; instead, the next call to read data will detect the closure and update the state. In this example, if the socket was closed cleanly, the read() call would return EOF to signal to the application that all data was safely received. If the connection was terminated abnormally, the call would throw an exception to indicate some data may have been lost.

It is reasonable to assume that a stream that has thrown an IOException is dead, and further attempts to read from it will continue to fail. If you could have detected this condition before making the call to read(), you'd presumably still handle it in the same way.

The exception to this approach is that some streams support a read timeout, where an exception is raised if no input is received for some time, but the stream remains valid. It would only make sense for a caller to pass such a stream to a method that explicitly supports retrying reads.