Um erro tipográfico em uma operação pode levar a resultados inesperados. Por exemplo, se a intenção é adicionar um número a uma variável usando +=, mas está escrito como =+, a operação ainda será válida. Porém, em vez de realizar a adição, a variável será reinicializada.

Exemplo 1 O código a seguir destina-se a adicionar um número à variável numberOne. No entanto, usar o operador =+ na verdade reinicializa a variável para 1.

uint numberOne = 1;

function alwaysOne() public {
    numberOne =+ 1;
}

Uma chamada feita para um contrato externo pode falhar, o que poderá causar uma Negação de serviço dentro do contrato de chamada se a falha não for tratada corretamente. O que pode deixar o contrato indisponível para uso posterior.

Isso é especialmente relevante quando a chamada externa é executada dentro de uma instrução de loop e ainda mais quando se lida com pagamentos, em que geralmente é melhor permitir que os usuários retirem fundos em vez de enviar fundos para eles.

Exemplo 1: O código a seguir usa uma instrução de loop for para reembolsar todos os endereços envolvidos usando a chamada externa send.

function refundAll() public {
    for(uint x; x < refundAddresses.length; x++) {
        require(refundAddresses[x].send(refunds[refundAddresses[x]]));
    }
}

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.