Has anyone ever seen an exception thrown when calling close method on any closable object?
I guess you could try to force this by unplugging the disk your file is on. But on any Closable
? I think it would be easy to get something that uses a socket to throw an exception upon closing.
I haven't, but it's possible. Imagine if there's an OutputStream
that for some reason hasn't written to the file yet. Well, calling close()
will flush out the data, but if the file is locked - then an IOException
would be raised.
Yes, it's not that rare, IMHO if you are working with anything other than non-local disk files.
Close() works if at that point your closable is still valid and open. Many things like pipes, remote files, etc., can die prematurely.
In addition, I have seen code that ignores errors on open and write and still tries to close (e.g., in a finally block).
An IOException
will be thrown on close
if the final flush
fails. Possible causes include:
- the file system is full, or the user is over quota,
- hard disc errors,
- a file system was forcibly unmounted,
- a remote file system is unavailable due to networking or other problems,
- (possibly) a character encoding error if writing to the file via an
OutputStreamWriter
or similar, - a device error if the "file" is a device file,
- a lost connection if the closeable is a network stream,
- a broken pipe if the closeable is a pipe to external process,
- and so on.
I have certainly seen some of these. Others are unlikely.
However, if the data you are writing is important then you should allow for close
failing. For example, if your application is writing out a critical file the file system fills up, your application had better notice this before it replaces the old copy of the file with the truncated version.
Not in terms of file-io, but in terms of sockets the close will raise IOException
when the other side has aborted the connection. For example, when you fire a HTTP request on a (large) webpage and then immediately navigate away by clicking another link on the webpage (while it isn't finished loading), then the server side will get an IOException
(or a subclass like ClientAbortException
in Tomcat servers and clones) when the outputstream of the HTTP response is to be flushed/closed.
Try yanking a USB drive with an open file on it. If it doesn't give an exception I'd be pretty surprised.