Avoid Catching Throwable

This is dangerous because it casts too wide a net; it can catch things like OutOfMemoryError.
Here's an example of code that would trigger this rule:

public class Foo {
 public void bar() {
  try {
   // do something
  } catch (Throwable th) {  //Should not catch throwable
   th.printStackTrace();
  }
 }
}



Signature Declare Throws Exception

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.
Here's an example of code that would trigger this rule:

public void methodThrowingException() throws Exception {
}

Preserve Stack Trace

Throwing a new exception from a catch block without passing the original exception into the new Exception will cause the true stack trace to be lost, and can make it difficult to debug effectively.
Here's an example of code that would violate this rule:   
   
public class Foo {
    void good() {
        try{
            Integer.parseInt("a");
        } catch(Exception e){
            throw new Exception(e);
        }
    }
    void bad() {
        try{
            Integer.parseInt("a");
        } catch(Exception e){
            throw new Exception(e.getMessage());
        }
    }
}

Exception As FlowControl

Using Exceptions as flow control leads to GOTOish code and obscures true exceptions when debugging.
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
  }
 }
}


Avoid Catching NPE

Code should never throw NPE under normal circumstances. A catch block may hide the original error, causing other more subtle errors in its wake.
Here's an example of code that would trigger this rule:

public class Foo {
 void bar() {
  try {
   // do something
   }  catch (NullPointerException npe) {
  }
 }
}


Avoid Throwing Raw Exception Types

Avoid throwing certain exception types. Rather than throw a raw RuntimeException, Throwable, Exception, or Error, use a subclassed exception or error instead.
Here's an example of code that would trigger this rule:

public class Foo {
public void bar() throws Exception {
  throw new Exception();
 }
}


Avoid Throwing NullPointerException

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.
Here's an example of code that would trigger this rule:

public class Foo {
 void bar() {
  throw new NullPointerException();
 }
}


Avoid Rethrowing Exception

Catch blocks that merely rethrow a caught exception only add to code size and runtime complexity.
Here's an example of code that would trigger this rule:

  public class Foo {
   void bar() {
    try {
    // do something
    }  catch (SomeException se) {
       throw se;
    }
   }
  }


Return From Finally Block

Avoid returning from a finally block - this can discard exceptions.
Here's an example of code that would trigger this rule:   
 
public class Bar {
 public String foo() {
  try {
   throw new Exception( "My Exception" );
  } catch (Exception e) {
   throw e;
  } finally {
   return "A. O. K."; // Very bad.
  }
 }
}


Logger Is Not Static Final

In most cases, the Logger can be declared static and final.
Here's an example of code that would violate this rule:   
 
class Foo{
    Logger log = Logger.getLogger(Foo.class.getName());
    // It is much better to declare the logger as follows
    // static final Logger log = Logger.getLogger(Foo.class.getName());

}

     
  Ref:
- PMD Strict Exception Rules