Since: PMD 1.2
This is dangerous because it casts too wide a net; it can catch things like OutOfMemoryError.
This rule is defined by the following Java class: net.sourceforge.pmd.rules.strictexception.AvoidCatchingThrowable
Example:
public class Foo {
public void bar() {
try {
// do something
} catch (Throwable th) { //Should not catch throwable
th.printStackTrace();
}
}
}
Since: PMD 1.2
It is unclear which exceptions that can be thrown from the methods. It might be difficult to document and understand the vague interfaces. Use either a class derived from RuntimeException or a checked exception.
This rule is defined by the following Java class: net.sourceforge.pmd.rules.strictexception.ExceptionSignatureDeclaration
Example:
public void methodThrowingException() throws Exception {
}
Since: PMD 1.8
Using Exceptions as flow control leads to GOTOish code and obscures true exceptions when debugging.
This rule is defined by the following Java class: net.sourceforge.pmd.rules.design.ExceptionAsFlowControl
Example:
public class Foo {
void bar() {
try {
try {
} catch (Exception e) {
throw new WrapperException(e);
// this is essentially a GOTO to the WrapperException catch block
}
} catch (WrapperException e) {
// do some more stuff
}
}
}
Since: PMD 1.8
Code should never throw NPE under normal circumstances. A catch block may hide the original error, causing other more subtle errors in its wake.
This rule is defined by the following XPath expression:
//CatchStatement/FormalParameter/Type
/ReferenceType/ClassOrInterfaceType[@Image='NullPointerException']
Example:
public class Foo {
void bar() {
try {
// do something
} catch (NullPointerException npe) {
}
}
}
Since: PMD 1.8
Avoid throwing certain exception types. Rather than throw a raw RuntimeException, Throwable, Exception, or Error, use a subclassed exception or error instead.
This rule is defined by the following XPath expression:
//AllocationExpression
/ClassOrInterfaceType[
(@Image='Throwable' and count(//ImportDeclaration/Name[ends-with(@Image,'Throwable')]) = 0)
or
(@Image='Exception' and count(//ImportDeclaration/Name[ends-with(@Image,'Exception')]) = 0)
or
(@Image='Error' and count(//ImportDeclaration/Name[ends-with(@Image,'Error')]) = 0)
or
( @Image='RuntimeException' and count(//ImportDeclaration/Name[ends-with(@Image,'RuntimeException')]) = 0)
]
Example:
public class Foo {
public void bar() throws Exception {
throw new Exception();
}
}
Since: PMD 1.8
Avoid throwing a NullPointerException - it's confusing because most people will assume that the virtual machine threw it. Consider using an IllegalArgumentException instead; this will be clearly seen as a programmer-initiated exception.
This rule is defined by the following XPath expression:
//AllocationExpression/ClassOrInterfaceType[@Image='NullPointerException']
Example:
public class Foo {
void bar() {
throw new NullPointerException();
}
}
Since: PMD 3.8
Catch blocks that merely rethrow a caught exception only add to code size and runtime complexity.
This rule is defined by the following XPath expression:
//CatchStatement[FormalParameter
/VariableDeclaratorId/@Image = Block/BlockStatement/Statement
/ThrowStatement/Expression/PrimaryExpression[count(PrimarySuffix)=0]/PrimaryPrefix/Name/@Image
and count(Block/BlockStatement/Statement) =1]
Example:
public class Foo {
void bar() {
try {
// do something
} catch (SomeException se) {
throw se;
}
}
}
Since: PMD 4.0
Errors are system exceptions. Do not extend them.
This rule is defined by the following XPath expression:
//ClassOrInterfaceDeclaration/ExtendsList/ClassOrInterfaceType
[@Image="Error" or @Image="java.lang.Error"]
Example:
public class Foo extends Error { }
Since: PMD 4.2
Throwing exception in a finally block is confusing. It may mask exception or a defect of the code, it also render code cleanup uninstable. Note: This is a PMD implementation of the Lint4j rule "A throw in a finally block"
This rule is defined by the following XPath expression:
//FinallyStatement[descendant::ThrowStatement]
Example:
public class Foo
{
public void bar()
{
try {
// Here do some stuff
}
catch( Exception e) {
// Handling the issue
}
finally
{
// is this really a good idea ?
throw new Exception();
}
}
}
Since: PMD 4.2.5
Catch blocks that merely rethrow a caught exception wrapped inside a new instance of the same type only add to code size and runtime complexity.
This rule is defined by the following XPath expression:
//CatchStatement[
count(Block/BlockStatement/Statement) = 1
and
FormalParameter/Type/ReferenceType/ClassOrInterfaceType/@Image = Block/BlockStatement/Statement/ThrowStatement/Expression/PrimaryExpression/PrimaryPrefix/AllocationExpression/ClassOrInterfaceType/@Image
and
count(Block/BlockStatement/Statement/ThrowStatement/Expression/PrimaryExpression/PrimaryPrefix/AllocationExpression/Arguments/ArgumentList/Expression) = 1
and
FormalParameter/VariableDeclaratorId = Block/BlockStatement/Statement/ThrowStatement/Expression/PrimaryExpression/PrimaryPrefix/AllocationExpression/Arguments/ArgumentList/Expression/PrimaryExpression/PrimaryPrefix/Name
]
Example:
public class Foo {
void bar() {
try {
// do something
} catch (SomeException se) {
// harmless comment
throw new SomeException(se);
}
}
}