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 "esta chamada de método jamais falha" e "não fará diferença se esta chamada falhar". Quando um programador ignora uma condição, ele declara implicitamente que está trabalhando sob uma dessas premissas.

Exemplo 1: O seguinte trecho de código ignora uma condição de erro que pode acontecer durante uma transação CICS.

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

Se uma transação em algum momento falhasse com essa condição de erro, o programa continuaria a ser executado como se nada de anormal tivesse ocorrido. O programa não registra nenhuma evidência que indique a situação especial, possivelmente frustrando qualquer tentativa posterior de explicar o comportamento do programa.

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 "esta chamada de método jamais falha" e "não fará diferença se esta chamada falhar". Quando um programador ignora uma exceção, ele afirma implicitamente estar operando de acordo com uma dessas suposições.

Exemplo 1: O seguinte trecho de código ignora uma exceção raramente lançada de doExchange().

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

Se uma RareException tivesse que ser lançada alguma vez, o programa continuaria a ser executado como se nada incomum tivesse ocorrido. O programa não registra nenhuma evidência que indique a situação especial, possivelmente frustrando qualquer tentativa posterior de explicar o comportamento do programa.

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.

Dois pressupostos duvidosos fáceis de detectar no código são "esta chamada de função nunca pode falhar" e "não importa se esta chamada falhar". Quando um programador ignora uma exceção, ele afirma implicitamente estar operando de acordo com uma dessas suposições.

Exemplo 1: Este código ignora várias exceções que podem ser lançadas durante a execução da instrução de inserção.

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

Uma exceção pode ser acionada porque a tabela não existe, um valor necessário não foi fornecido, ou por algum outro motivo. Se houver uma falha, não há nenhuma maneira de dizer, uma vez que o procedimento não a relatará ou registrará que tipo de falha ocorreu.

Vários blocos "catch" podem se tornar repetitivos, mas a "condensação" desses blocos por meio da captura de uma classe de alto nível, como Exception, pode obscurecer exceções que merecem tratamento especial ou que não devem ser detectadas a essa altura no programa. A captura uma exceção excessivamente ampla destrói em essência a finalidade de exceções de Java com tipo definido, podendo tornar-se um procedimento particularmente perigoso se o programa crescer e começar a lançar novos tipos de exceções. Os novos tipos de exceção não receberão nenhuma atenção.

Exemplo: O seguinte trecho de código lida com três tipos de exceções de modo idêntico.

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

À primeira vista, pode parecer preferível lidar com essas exceções em um único bloco "catch", da seguinte maneira:

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

No entanto, se doExchange() for modificado de forma a lançar um novo tipo de exceção que deve ser tratado de maneira diferente, o bloco "catch" amplo impedirá que o compilador aponte a situação. Além disso, o novo bloco "catch" também passará a lidar com exceções derivadas de RuntimeException, como ClassCastException e NullPointerException, o que não é a intenção do programador.

Declarar um método para lançar Exception ou Throwable dificulta o trabalho de tratamento de erros e recuperação por parte dos chamadores. O mecanismo de exceção do Java está configurado para facilitar a tarefa dos chamadores de antecipar o que pode dar errado e escrever um código para lidar com cada circunstância excepcional específica. Declarar que um método lança uma forma genérica de exceção derrota esse sistema.

Exemplo: O método a seguir lança três tipos de exceções.

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

Embora possa parecer mais apropriado escrever

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

isso dificulta a capacidade do chamador de compreender e lidar com as exceções que possam ocorrer. Além disso, se uma revisão posterior de doExchange() introduz um novo tipo de exceção que deve ser tratado de forma diferente do que exceções anteriores, não haverá nenhuma maneira simples de fazer cumprir essa exigência.

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.