No compilation error on Runtime Exceptions. why?

In the Below example if RuntimeException is replaced with some other exc开发者_如何学Ception then compiler throws the compilation error. But for Runtime Exception's it is not throwing anything. Why? Please explain.

class A {
    public void process() {
        System.out.print("A,");

    }
}

class B extends A {
    public void process() throws RuntimeException {
        System.out.print("B,");
        throw new RuntimeException();
    }

    public static void main(String[] args) {
        A a = new B();
        a.process();
    }
}

RuntimeExceptions are what we call "unchecked exceptions".

This means, the compiler does not check whether they're caught in code.

The reason for this is, we have some exceptions that we often prefer to not have to handle or declare. For instance, NullPointerExceptions can potentially be thrown at so many places in the code, that it's more convenient if we only handle them, if we explicitly decide to.

See also:

• In Java, when should I create a checked exception, and when should it be a runtime exception?
• Unchecked Exceptions — The Controversy
• Java unchecked/checked exception clarification

This has to do with checked vs unchecked exceptions. Here is another brief explanation

That's why it's called RuntimeException :)

Seriously, RuntimeException (all all exceptions inheriting from it) are called "unchecked exceptions" and the whole point is that they are NOT checked by the compiler.

This is required of a compiler, due to the following requirement in the Java Language Specification

11.2.5 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.

For example, certain code might implement a circular data structure that, by construction, can never involve null references; the programmer can then be certain that a NullPointerException cannot occur, but it would be difficult for a compiler to prove it. The theorem-proving technology that is needed to establish such global properties of data structures is beyond the scope of this specification.

Unlike checked exceptions, runtime exceptions (or unchecked exceptions) do not define a contract between the caller and the called method, for they usually indicate an erroneous condition, that is often resolved by the caller if it were to obey the contract.

If a compiler were to be given the task of enforcing such a contract, it would result in additional complexity (in the language itself and in the code that people write). Imagine, enforcing every method to check for null arguments and requiring programmers to throw such exceptions (and also declare such exceptions in the throws clause). The easier way out, is to specify a contract that states that a method will not operate on null arguments and that a caller should expect to catch NullPointerExceptions; if the caller wants to avoid this scenario, it must check the arguments before invoking the method.

The reason for that is the fact that checked exceptions declared for the overriding method must match with the signature of the method overridden. Otherwise the code won't compile due to the method signature mismatch. It is fine when you declare unchecked exceptions in overriding method, because these exceptions as the name suggest are not checked by the compiler.