Declaring a method to throw Exception or Throwable makes it difficult for callers to do good error handling and error recovery. Java's exception mechanism is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system.

Example: The following method throws three types of exceptions.

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

While it might seem tidier to write

public void doExchange()
  throws Exception {
  ...
}

doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

Programmers typically catch NullPointerException under three circumstances:

1. The program contains a null-pointer dereference. Catching the resulting exception was easier than fixing the underlying problem.

2. The program explicitly throws a NullPointerException to signal an error condition.

3. The code is part of a test harness that supplies unexpected input to the classes under test.

Of these three circumstances, only the last is acceptable.

Example: The following code mistakenly catches a NullPointerException.

  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }

Programmers typically catch NullReferenceException under three circumstances:

1. The program contains a null-pointer dereference. Catching the resulting exception was easier than fixing the underlying problem.

2. The program explicitly throws a NullReferenceException to signal an error condition.

3. The code is part of a test harness that supplies unexpected input to the classes under test.

Of these three circumstances, only the last is acceptable.

Example: The following code mistakenly catches a NullReferenceException.

  try {
    MysteryMethod();
  }
  catch (NullReferenceException npe) {
  }

A return statement inside a finally block will cause any exception that might be thrown in the try block to be discarded.

Example 1: In the following code excerpt, the MagicException thrown by the second call to doMagic with true passed to it will never be delivered to the caller. The return statement inside the finally block will cause the exception to be discarded.

public class MagicTrick {

public static class MagicException extends Exception { }

public static void main(String[] args) {

  System.out.println("Watch as this magical code makes an " +
                     "exception disappear before your very eyes!");

  System.out.println("First, the kind of exception handling " +
                     "you're used to:");
  try {
    doMagic(false);
  } catch (MagicException e) {
    // An exception will be caught here
    e.printStackTrace();
  }

  System.out.println("Now, the magic:");
  try {
    doMagic(true);
  } catch (MagicException e) {
    // No exception caught here, the finally block ate it
    e.printStackTrace();
  }
  System.out.println("tada!");
}

public static void doMagic(boolean returnFromFinally)
throws MagicException {

  try {
    throw new MagicException();
  }
  finally {
    if (returnFromFinally) {
      return;
    }
  }
}

}

ThreadDeath errors should only be caught if an applications needs to clean up after being terminated asynchronously. If a ThreadDeath error is caught, it is important that it be re-thrown so that the thread actually dies. The purpose of throwing ThreadDeath is to stop a thread. If ThreadDeath is swallowed, it can prevent a thread from stopping and result in unexpected behavior since whoever originally threw ThreadDeath expects the thread to stop.

Example 1: The following code catches ThreadDeath but does not re-throw it.

try
{
//some code
}
catch(ThreadDeath td)
{
//clean up code
}

In Java, finally blocks are always executed after their corresponding try-catch blocks and are often used to free allocated resources, such as file handles or database cursors. Throwing an exception in a finally block can bypass critical cleanup code since normal program execution will be disrupted.

Example 1: In the following code, the call to stmt.close() is bypassed when the FileNotFoundException is thrown.

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}

Unhandled exception vulnerabilities occur when:

1. An exception is thrown

2. The exception is not properly handled before it escapes the current page.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this operation can never fail" and "it doesn't matter if this operation fails". When a programmer fails to catch an exception that an operation may throw, they implicitly state that they are operating under one of these assumptions.