How are RuntimeExceptions not checked by compiler, even though they extend Exception class?

Question

When we create a CustomException by extending Exception class it is checked by compiler, but even though RuntimeExceptions extend Exception class are they not checked by the compiler.

How is this established in the compiler. I found a section in JLS stating why.

Why Runtime Exceptions are Not Checked
The runtime exception classes (RuntimeException and its subclasses) are exempted from compile-time checking because, in the judgment of the designers of the Java programming language, having to declare such exceptions would not aid significantly in establishing the correctness of programs. Many of the operations and constructs of the Java programming language can result in runtime exceptions. The information available to a compiler, and the level of analysis the compiler performs, are usually not sufficient to establish that such run-time exceptions cannot occur, even though this may be obvious to the programmer. Requiring such exception classes to be declared would simply be an irritation to programmers.

Is there something happens behind the scenes like in the case of marker interfaces.

I am looking for some source that can explain how it is done and also why there is no parent class for all checked exceptions?

Answer 1

Is there something happens behind the scenes like in the case of marker interfaces.

The fact that RuntimeException is exempted from the rule that all subclasses of Exception are checked exceptions is simply part of the spec.

How this exception to the rule is implemented is compiler dependent.

Answer 2

The compiler checks all Throwable sub-classes except sub-classes of Error and RuntimeException. It just checks whether the Throwable is a sub-class of these classes.

Note: you can have a sub-class of Throwable which is not an Error or an Exception and it will be checked.

Answer 3

At any point in time, someone can enter zero into your program. If you ever divide, that could result in a divide by zero error, which will throw a RuntimeExcpetion called ArithmeticException.

Now if you needed to include try / catch blocks around all of your division statements, the code would be cluttered with error handling that detracted from the readability of the main purpose of the code, which might be anything (but probably isn't about catching divide by zero errors).

Java either had the choice to strike a balance between readability and robustness, or to allow robustness in all cases with some "assumptions" that enhanced readability. In other words, when the Java language was being laid out, a decision to balance readability with robustness would look like a decision between polluting user written source code with a need to capture ArithmeticExcpetions around any division operation. The alternative, which is to always ensure robustness, but make certain kinds of Exceptions not subject to required capture, ensures program robustness without an impact on source code readability (at the cost of knowing that the language is slightly more complex because it has two categories of Exceptions).