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

Question 1

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.

Question 2

RuntimeException and its subclasses are unchecked exceptions. All others are checked exceptions.

Question 3

You can find the definition of unchecked exceptions in the Java Tutorials (emphasis mine):

...the Java programming language does not require methods to catch or to specify unchecked exceptions (RuntimeException, Error, and their subclasses)...

Question 4

Rather than "caught vs uncaught" they are called "checked vs. unchecked" exceptions. At compile-time checked exceptions are controlled i.e. compiler warns you if something doesn't comply with the exception contract, but unchecked ones can be thrown at runtime.

Question 5

If you are using an IDE the easiest way if if your IDE gives you an error/underline telling you that you have an unhandled exception when you don't catch it. Those ones are checked exceptions.

Alternatively, anything that inherits from RuntimeException is unchecked.

Question 6

The inheritance tree for Throwable actually goes:

Throwable     Error
              Exception   RuntimeException

Places that throw anything extending Error or RuntimeException do not need to be declared. Errors are usually only thrown by the JVM and signal something very bad happening.

Anything extending Exception but not extending RuntimeException do need to be declared. In general Exceptions are things that should be handled or considered by the calling code (for example "could not open a file") whereas RuntimeExceptions are things that probably indicate a bug in the code or corrupted data such as NullPointerException and so it's unlikely the calling code can do anything about it.

Question 7

If your using any method or code which throws exception explicitly, you need to catch that exception and by looking at code we are sure that we need to catch so this is checked Exception. In case of RuntimeException by looking at code you can not assure of this code will throw exception so they are unchecked.

Java doc reference

Any Exception that can be thrown by a method is part of the method's public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them. These exceptions are as much a part of that method's programming interface as its parameters and return value.

Question 8

As the javadoc stated:

RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine. A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.

Author(s): Frank Yellin

Since: JDK1.0

Now, returning back to your question, I wonder if the difference is defined inside the interpreter itself? .... the magic trick is done inside the bytecode.

The article below shows it, by analysing the bytecode:

http://www.javaworld.com/article/2076868/learn-java/how-the-java-virtual-machine-handles-exceptions.html

The basic mecanism is the exception table :

Exception table:
   from   to  target type
     0     4     4   <Class java.lang.ArithmeticException>

If an exception is thrown during the execution of a method, the Java virtual machine searches through the exception table for a matching entry.

An exception table entry matches if the current program counter is within the range specified by the entry, and if the exception class thrown is the exception class specified by the entry (or is a subclass of the specified exception class).

The Java virtual machine searches through the exception table in the order in which the entries appear in the table. When the first match is found, the Java Virtual Machine sets the program counter to the new pc offset location and continues execution there.

If no match is found, the Java virtual machine pops the current stack frame and rethrows the same exception.

When the Java virtual machine pops the current stack frame, it effectively aborts execution of the current method and returns to the method that called this method. But instead of continuing execution normally in the previous method, it throws the same exception in that method, which causes the Java virtual machine to go through the same process of searching through the exception table of that method.