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); } } }