java: throws RuntimeException [duplicate]

Question

How is the below one correct? I expected compiler to tell me to use throws Exception or throws RuntimeException

public void method1() throws NullPointerException { 

        throw new RuntimeException();
    }

why I think its not correct -> Bcoz a NPE is a RTE, but a RTE is not a NPE

How is this correct? I expected compiler to tell me to use throws Exception or throws RuntimeException or throws NumberFormatException

public void method2() throws NullPointerException { 


    throw new NumberFormatException();
}


public void method3() throws Exception { // this is fine, as expected

        throw new RuntimeException();
    }


    public void method4() throws RuntimeException { // this is fine, as expected

        throw new NullPointerException();
    }

    public void method5() throws Exception { // this is fine, as expected

        throw new NullPointerException(); 
    }

Answer:

for RTE even if u don't add throws clause to the method, compiler won't say anything

public void method6()  { // no compile time errors!!

        throw new NullPointerException(); 
    }

But when we explicitly say that 'throw new NullPointerException();' , why compiler ignores it? It is same as 'throw new SQLException();' It is not thrown on runtime say some object was evaluated to null, and invoked an action on that null object. Normally a function must declare all the exceptions that it can throw, but RTE's is bypassing it!

RTE's are unchecked exceptions. But when you say throw new RTE, still unchecked?!

Question - Isn't this a flaw? or please correct me in understanding why is it like that

• Update:

Please note that this question is not about difference between checked exception and unchecked exception. The question is not about difference between any type of exception or error.

The question is why an explicitly marked RunTimeException is not handled, or left without forcing the compiler to handle it.

eg:

public void methodA() { // methodA is not forced to handle the exception.
        methodB(); 
    }

    public void methodB() throws RuntimeException {

    }

Answer 1

I think I understand the question, you want to know if it's a design flaw that whatever exception you include in a method's throws clause doesn't get counted as checked.

The core premise of checked exceptions was that we could tell, at the site where an exception was thrown, whether anyone would want to handle this exception or not. There wasn't any consideration if a NullPointerException should be considered as checked in some contexts but not in others, the idea was that it was always one thing or another. Also for this to be included initially this would have been more code to write at a time when there were tight deadlines, and after that a change to this would've meant breaking existing user code. So that's likely why Java doesn't have that feature.

Answer 2

You misunderstand.

Checked exceptions are exceptions that are checked ( hence their name ) at compile-time. Hence, if you have method doFoo that throws exception BarException, you must declare that the method throws BarException :

void doFoo() throws BarException { }

Unchecked exceptions are exceptions that are not checked by the compiler, so you do not have to declare that you throw them

Saying throw new Exception() merely throws a new instance of a checked exception, or unchecked in the case of RuntimeException. The case where the checking factors in is only when you are actually throwing a checked exception using the throw clause.

As far as whether or not it is a flaw, now that's a heavily opinionated topic. It tends to be rather annoying to use APIs that throw tons of unchecked exceptions without documenting that they throw those exceptions. However, sometimes it is possible to have exceptions that occur based on the unique runtime state of an application, where you could not declare that a certain checked exception could be thrown, and that is where runtime exceptions shine (like NullPointerException)