An exception in a throws declaration in Java is superfluous if it is:
- listed multiple times
- a subclass of another listed exception
- completely unnecessary because the declared exception type cannot actually be thrown
Noncompliant Code Example
void foo() throws MyException, MyException {} // Noncompliant; should be listed once
void bar() throws Throwable, Exception {} // Noncompliant; Exception is a subclass of Throwable
Compliant Solution
void foo() throws MyException {}
void bar() throws Throwable {}
Exceptions
The rule will not raise any issue for exceptions that cannot be thrown from the method body:
- in overriding and implementation methods
- in interface
default methods
- in non-private methods that only
throw, have empty bodies, or a single return statement.
- in overridable methods (non-final, or not member of a final class, non-static, non-private), if the exception is documented with a proper
JavaDoc
Also, the rule won’t raise issues on RuntimeException, or one of its descendants, because explicating runtime exceptions which could
be thrown can ultimately help the method’s users, and can even be considered as good practice.
class A extends B {
@Override
void doSomething() throws IOException {
compute(a);
}
public void foo() throws IOException {}
public void qix() throws MyRuntimeException {}
protected void bar() throws IOException {
throw new UnsupportedOperationException("This method should be implemented in subclasses");
}
Object foobar(String s) throws IOException {
return null;
}
/**
* @throws IOException Overriding classes may throw this exception if they print values into a file
*/
protected void print() throws IOException { // no issue, method is overridable and the exception has proper javadoc
System.out.println("foo");
}
}
