Em geral, os programadores capturam NullPointerException em três circunstâncias:

1. O programa contém um cancelamento de referência a ponteiro nulo. Capturar a exceção resultante foi mais fácil do que corrigir o problema subjacente.

2. O programa lança explicitamente uma NullPointerException para sinalizar uma condição de erro.

3. O código faz parte de um conjunto de teste que fornece entradas inesperadas para as classes sob teste.

Dessas três circunstâncias, somente a última é aceitável.

Exemplo: O seguinte código captura uma NullPointerException por engano.

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

Em geral, os programadores capturam NullReferenceException em três circunstâncias:

1. O programa contém um cancelamento de referência a ponteiro nulo. Capturar a exceção resultante foi mais fácil do que corrigir o problema subjacente.

2. O programa lança explicitamente uma NullReferenceException para sinalizar uma condição de erro.

3. O código faz parte de um conjunto de teste que fornece entradas inesperadas para as classes sob teste.

Dessas três circunstâncias, somente a última é aceitável.

Exemplo: O seguinte código captura uma NullReferenceException por engano.

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

Uma instrução de retorno dentro de um bloco finally fará com que qualquer exceção que possa ser lançada no bloco "try" seja descartada.

Exemplo 1: No seguinte trecho de código, a MagicException lançada pela segunda chamada para doMagic com true transmitido para ela nunca será entregue para o chamador. A instrução de retorno dentro do bloco finally fará com que a exceção seja descartada.

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

}

Erros de ThreadDeath só devem ser capturados se um aplicativos precisar de uma limpeza depois de ter sido finalizado de forma assíncrona. Se um erro ThreadDeath for capturado, é importante que ele seja novamente lançado para que o thread realmente seja desativado. O objetivo de lançar ThreadDeath é interromper um thread. Se ThreadDeath for engolido, ele poderá impedir que um thread seja interrompido e resultar em um comportamento inesperado, pois, quem quer que tenha lançado ThreadDeath originalmente, espera que o thread seja interrompido.

Exemplo 1: O código a seguir captura ThreadDeath, mas não volta a lançá-lo.

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

Em Java, blocos finally são sempre executados depois de seus blocos try-catch correspondentes e são frequentemente utilizados para liberar recursos alocados, como identificadores de arquivos ou cursores de banco de dados. Lançar uma exceção em um bloco finally pode ignorar o código de limpeza crítico, pois a execução normal do programa será interrompida.

Exemplo 1: No código a seguir, a chamada para stmt.close() é ignorada quando a FileNotFoundException é lançada.

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

Vulnerabilidades de exceção sem tratamento ocorrem quando:

1. Uma exceção é lançada

2. A exceção não é devidamente tratada antes de escapar da página atual.

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas premissas duvidosas que são fáceis de detectar no código são "essa operação nunca pode falhar" e "não importa se essa operação falhar". Quando os programadores não conseguem capturar uma exceção que uma operação pode lançar, eles afirmam implicitamente que estão operando segundo uma dessas premissas.

Vulnerabilidades de exceção SSL sem tratamento ocorrem quando:

1. Uma exceção específica de SSL é lançada.

2. A exceção não é explicitamente manipulada.

As exceções específicas de SSL javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLKeyException e javax.net.ssl.SSLPeerUnverifiedException transmitem erros importantes relacionados a uma conexão SSL. Se esses erros não forem tratados explicitamente, a conexão poderá ser deixada em um estado inesperado e potencialmente inseguro.

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas premissas duvidosas que são fáceis de detectar no código são "essa operação nunca pode falhar" e "não importa se essa operação falhar". Quando os programadores não conseguem capturar uma exceção que uma operação pode lançar, eles afirmam implicitamente que estão operando segundo uma dessas premissas.