##### Overview

- Download PMD 4.2.5
- What's new in PMD 4.2.5
- PMD in the news
- PMD-related products and books
- Best practices
- Future directions
- Similar projects
- Credits
- License
- What does 'PMD' mean?

##### Usage

- Installation
- Command line usage
- Ant task usage
- Maven plugin usage
- Mvn plugin usage
- IDE plugin usage
- Suppressing warnings
- Finding duplicated code
- JSP support

##### Customizing PMD

- Compiling PMD
- How to write a rule
- Writing XPath rules
- How to make a rule set
- How it works
- Rule guidelines

##### For example

- Run PMD on a Sourceforge project

##### Rule Sets

- Index
- Android
- Basic
- Braces
- Code Size
- Clone
- Controversial
- Coupling
- Design
- Finalizers
- Import Statements
- J2EE
- Javabeans
- JUnit Tests
- Logging (Java)
- Logging (Jakarta)
- Migrating
- Naming
- Optimizations
- Strict Exceptions
- Strings
- Sun Security
- Unused Code
- Java Server Pages
- Java Server Faces

##### Project Documentation

- About
- Project Info
- Project Reports
- Development Process

##### Legend

- External Link
- Opens in a new window

## Strict Exception Rules

These rules provide some strict guidelines about throwing and catching exceptions.

### AvoidCatchingThrowable

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

### SignatureDeclareThrowsException

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 {
    }

### ExceptionAsFlowControl

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

### AvoidCatchingNPE

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

### AvoidThrowingRawExceptionTypes

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

### AvoidThrowingNullPointerException

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

### AvoidRethrowingException

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

### DoNotExtendJavaLangError

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 { }

### DoNotThrowExceptionInFinally

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

### AvoidThrowingNewInstanceOfSameException

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