Strict Exception Rules

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

AvoidCatchingThrowable

This is dangerous because if a java.lang.Error, for example OutOfMemmoryError, occurs then it will be caught. The container should handle java.lang.Error. If application code will catch them, try to log them (which will probably fail) and continue silently the situation will not be desirable.

This rule is defined by the following Java class: net.sourceforge.pmd.rules.strictexception.AvoidCatchingThrowable

Here's an example of code that would trigger this rule:

			
                
SimpleDateFormat sdf = null;
try {
    sdf = new SimpleDateFormat("yyyy-MM-dd");
} catch (Throwable th) {  //Should not catch throwable
    th.printStackTrace();
}

SignatureDeclareThrowsException

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

Here's an example of code that would trigger this rule:

			
                
public void methodThrowingException() throws Exception {
}

ExceptionTypeChecking

At some places Exception is caught and then a check with instanceof is performed. This result in messy code. It's considered better to catch all the specific exceptions instead.

This rule is defined by the following Java class: net.sourceforge.pmd.rules.strictexception.ExceptionTypeChecking

Here's an example of code that would trigger this rule:

			
                
SimpleDateFormat sdf = new SimpleDateFormat("dd.MM.yyyy");
try {
    returnString = sdf.format(value);
} catch (Exception ex) {
    /* BAD STUFF !!!*/
    if (ex instanceof NumberFormatException) {
        System.out.println("NumberFormat exception!!!");
    }
    if (ex instanceof IllegalArgumentException) {
        System.out.println("illegal argument...!!!");
    }
}

ExceptionAsFlowControl

Using Exceptions as flow control leads to GOTOish code.

This rule is defined by the following Java class: net.sourceforge.pmd.rules.design.ExceptionAsFlowControl

Here's an example of code that would trigger this rule:

			
  
  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

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:

            
//TryStatement/FormalParameter/Type
 /ReferenceType/ClassOrInterfaceType[@Image='NullPointerException']

Here's an example of code that would trigger this rule:

			  
try {
  ...
} catch (NullPointerException npe) {
  ...
}

AvoidThrowingCertainExceptionTypes

1) Avoid throwing certain exception types. Rather than throw a raw RuntimeException, Throwable, Exception, or Error, use a subclassed exception or error instead. 2) Avoid throwing a NullPointerException - it's confusing because most people will assume that the VM threw NPE. Consider using InvalidArgumentException("Null parameter") which will be clearly seen as a programmer initiated exception.. Use IllegalArgumentException or IllegalStateException instead.

This rule is defined by the following XPath expression:

            
//AllocationExpression
 /ClassOrInterfaceType[
 @Image='Throwable' |
 @Image='Exception' |
 @Image='Error' |
 @Image='RuntimeException' |
 @Image='NullPointerException']

Here's an example of code that would trigger this rule:

			
      
throw new Exception();