A RuntimeException could be thrown by any code. In other words, the compiler can’t easily predict what kind of code can throw it. A RuntimeException can be caught by a catch(Exception e) block.
IOException, however, is a checked exception – only method calls which are declared to throw it can do so. The compiler can be (reasonably) confident that it can’t possible occur unless there are method calls which are declared to throw it.
The Java compiler simply doesn’t consider the “there’s no code at all within the try block” situation – it always allows you to catch unchecked exceptions, as in all reasonable scenarios there will be code which could potentially throw an unchecked exception.
From section 14.21 of the JLS:
A catch block C is reachable iff both of the following are true:
- Some expression or throw statement in the try block is reachable and can throw an exception whose type is assignable to the parameter of the catch clause C. (An expression is considered reachable iff the innermost statement containing it is reachable.)
- There is no earlier catch block A in the try statement such that the type of C’s parameter is the same as or a subclass of the type of A’s parameter.
Arguably the compiler should realize that there are no expressions within the try block in your first case… it looks like this is still an unreachable catch clause, to me.
EDIT: As noted in comments, section 14.20 contains this:
It is a compile-time error if a
catchclause catches checked exception type E1 but there exists no checked exception type E2 such that all of the following hold:
- E2 <: E1
- The
tryblock corresponding to thecatchclause can throw E2- No preceding
catchblock of the immediately enclosing try statement catches E2 or a supertype of E2.unless E1 is the class Exception.
So it looks like that’s what you’re actually running foul of, but the spec isn’t as clear as it could be in terms of unreachable catch blocks in 14.21.