Question

What is the benefit of declaring (Unchecked Exception)throws exception along method signature b/c it does not force caller to keep in try catch block.

public void testRuntimeEx()throws RuntimeException{

if(1==1){throw new RuntimeException()}

}

//Caller method
public void testCaller(){
// not necessery to handle even caller does not known which RuntimeException might be throws then what is the benefit throws clause with method signature
testRuntimeEx(); 

}
Was it helpful?

Solution 4

if you throw custom unchecked exception it becomes more meaningfull rather catching system exception and unchecked exception does not force to catch too.

OTHER TIPS

It still serves as documentation, especially if you do not use a generic RuntimeException, but something more specific like IllegalArgumentException or UnsupportedOperationException or IndexOutOfBoundsException and also add some JavaDoc as to when that would happen.

In your example code snippet, it is pretty meaningless, though.

This declaring is a signal for developer who uses this code, that it throws RuntimeException. But it doesn't smell good.

P.S. Code you posted will not compile:

throw RuntimeException

This is not correct throwing.

The benefit is that typically caller does not have anything to do with the exception. It catches it, wraps with other exception and throws again. Or, alternatively, declares the exception using throws keyword and becomes transparent for this type if exception.

I'd say that the described situation is typical for applications where we usually write business code and have one centralized place that handles all exceptions. It is not correct for APIs. For example if you are using library that implements SSH you are expecting it to throw IOException (or even more specialize exception) when something is going wrong.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top