Search code examples
javaunchecked-exception

Java - checked vs unchecked Exception - tell from code alone?

Is it possible to tell if an exception class is a checked or unchecked just by looking at the code? I always thought that if it extended Exception, it was checked, but then RuntimeException extends Exception and that is unchecked. RuntimeException may be the only class that bends that rule of thumb, with other unchecked exceptions having to extend Throwable if not extending RuntimeException. However, I do not see how RuntimeException differs from Exception. I wonder if the difference is defined inside the interpreter itself?

Solution

  • Is it possible to tell if an exception class is a checked or unchecked just by looking at the code?

    Yes. If you know the rules ... as specified in the JLS (11.1.1) ... and you can also see the code of the exceptions' superclasses (so that you can check the hierarchy).

    The rules are that exceptions are "checked" except for the following:

    • RuntimeException and its subclasses, and

    • Error and its subclasses,

    which are "unchecked".

    I wonder if the difference is defined inside the interpreter itself?

    No. It is in the Java Language Spec. In fact, the JVM treats checked and unchecked exceptions the same. All the checking that checked exceptions are treated correctly is done by the Java compiler.

    However, I still do not understand the reasoning that RuntimeException extends Exception rather than Throwable. That design choice seems contradictory, given that there is nothing in RuntimeException that overrides behavior defined in Exception.

    It is the way it is. And besides, I don't see any logical contradiction.

    • An Error represents an unrecoverable condition. It is unchecked because there is no point forcing the application to do something about it.

    • An Exception represents a potentially recoverable condition.

    • A RuntimeException represents a potentially recoverable condition that we don't want to force the application to deal with. (But it could, if it wanted to).

    Clearly, by this taxonomy, a RuntimeException >>is<< an Exception and >>not<< an Error ... and that is the rationale for defining the exception class hierarchy that way.