Should class IOException in Java have been an unchecked RuntimeException?

Question

Do you agree that the designers of Java class java.io.IOException should have made it an unchecked run-time exception derived from java.lang.RuntimeException instead of a checked exception derived only from java.lang.Exception?

I think that class IOException should have been an unchecked exception because there is little that an application can do to resolve problems like file system errors. However, in When You Can't Throw An Exception, Elliotte Rusty Harold claims that most I/O errors are transient and so you can retry an I/O operation several times before giving up:

For instance, an IOComparator might not take an I/O error lying down, but — because many I/O problems are transient — you can retry a few times, as shown in Listing 7:

Is this generally the case? Can a Java application correct I/O errors or wait for the system to recover? If so, then it is reasonable for IOException to be checked, but if it is not the case, then IOException should be unchecked so that business logic can delegate handling of this exception to a separate system error handler.

Answer 1

No because you can recover from some IOExceptions. Most notable ones are low level indexed reads and writes. If it fails, sometimes you can just retry without harm.

Answer 2

I completely disagree. To me the model is correct. A RuntimeException is one which most typically denotes a serious error in the logic of the programming (such as ArrayIndexOutOfBounds, NullPointer, or IllegalArgument) or something that the runtime has otherwise determined really shouldn't be happening (such as SecurityException).

Conversely IOException and its derivatives are exceptions that could reasonably occur during normal execution of a program, and common logic would dictate that either those problems should be dealt with, or at least the programmer should be aware that they can occur. For example with Files if you're application logger can't write its data would you rather be forced to catch a potential IOException and recover, or have something that may not be critical to your app bring down the whole JVM because no one thought to catch the unchecked Exception (as you may have guessed, I'll choose the former).

I think that there are many situations in which an IOException is either recoverable, or at the least the programmer should be explicitly aware of the potential so that if it is not recoverable the system might be able to crash more "gently".

As far your thought of if the system can not recover there are always alternatives with a checked exception. You can always have your methods declare it in their throws, throw a runtime excpetion of their own or crash the JVM violently:

public void doit() throws IOException {
  try{
  }catch(IOException e){
    //try to recover
    ...

    //can't recover
    throw e;
  }
}

public void doit() {
  try{
  }catch(IOException e){
    //try to recover
    ...

    //can't recover
    throw new RuntimeException(e);
  }
}



public void doit() {
  try{
  }catch(IOException e){
    //try to recover
    ...

    //OH NO!!!!
    System.exit(Constant.UNRECOVERABLE_IO_ERROR);
  }
}

Answer 3

I think it is clever to leave it a checked exception. I regard runtime exceptions as bugs, and this is clearly not the case. Recovery by retry is sometimes possible, and also some IOException messages can be informative to the end user (e.g. no permissions to write, not enough disk space, etc).

Answer 4

Probably the vast majority of IO exceptions are recoverable - permissions errors, lack of space on the drive, connection closed, etc, etc. I believe unchecked exceptions are supposed to be used for "there's no reasonable way to recover from this" sorts of situations.