Un error tipográfico en una operación puede generar resultados inesperados. Por ejemplo, si la intención es agregar un número a una variable usando +=, pero está escrito como =+, la operación sigue siendo válida. Sin embargo, en lugar de realizar la suma, reinicializa la variable.

Ejemplo 1 El siguiente código está destinado a agregar un número a la variable numberOne. Sin embargo, el uso del operador =+ en realidad reinicializa la variable a 1.

uint numberOne = 1;

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

Una llamada realizada a un contrato externo puede fallar, lo que podría causar una denegación de servicio dentro del contrato de llamada si el fallo no se maneja correctamente. Ello puede dejar el contrato no disponible para su uso posterior.

Esto es especialmente relevante cuando la llamada externa se ejecuta dentro de una declaración de bucle y aún más cuando se trata de pagos, donde suele ser mejor permitir que los usuarios retiren fondos en lugar de enviarles fondos.

Ejemplo 1: El siguiente código utiliza una instrucción de bucle for para reembolsar a todas las direcciones involucradas mediante el uso de send llamada externa.

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

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta llamada de método no puede tener nunca errores" y "no importa si se produce un error en esta llamada". Cuando un programador ignora una condición, implícitamente indica que está funcionando según uno de estos supuestos.

Ejemplo 1: el siguiente fragmento de código ignora una condición de error que puede darse durante una transacción de CICS.

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

Si una transacción nunca hubiese fallado con esta condición de error, el programa debería seguir ejecutándose como si nada inusual hubiese ocurrido. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta llamada de método no puede tener nunca errores" y "no importa si se produce un error en esta llamada". Cuando un programador ignora una excepción, implícitamente indica que está funcionando según uno de estos supuestos.

Ejemplo 1: El fragmento de código siguiente ignora una excepción iniciada en pocas ocasiones desde doExchange().

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

Si una RareException se fuese a iniciar en algún momento, el programa seguiría ejecutándose como si no hubiese ocurrido nada inusual. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta llamada de función no puede tener nunca errores" y "no importa si se produce un error en esta llamada". Cuando un programador ignora una excepción, implícitamente indica que está funcionando según uno de estos supuestos.

Ejemplo 1: el siguiente código pasa por alto varias excepciones que se podrían producir al ejecutar la instrucción INSERT.

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

Se podría producir una excepción porque no existe la tabla, no se ha proporcionado un valor requerido o por alguna otra razón. Si se produce un error, no hay ninguna manera de saberlo porque el procedimiento no informa del error ni registra el tipo de error producido.

Si los bloques catch son varios, pueden volverse repetitivos, pero si se "condensan" bloques catch obteniendo una clase de alto nivel como Exception, se pueden ocultar excepciones que requieran un tratamiento especial o que no se deberían obtener en este punto del programa. Si se obtiene una excepción demasiado amplia, básicamente hace fracasar el propósito de las excepciones tipificadas de Java, y puede resultar particularmente peligroso si el programa se desarrolla y comienza a iniciar nuevos tipos de excepciones. Los nuevos tipos de excepciones quedarán desatendidas.

Ejemplo: El fragmento de código siguiente trata tres tipos de excepciones de manera idéntica.

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

A primera vista, puede parecer preferible tratar estas excepciones en un solo bloque catch, de la siguiente forma:

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

No obstante, si se modifica doExchange() para iniciar un nuevo tipo de excepción que debería tratarse de forma diferente, el amplio bloque catch evitará que el compilador señale la situación. Es más, el nuevo bloque de filtrado ahora también administra las excepciones derivadas de RuntimeException como ClassCastException y NullPointerException, que no es el propósito del programador.

Declarar un método para lanzar Exception o Throwable dificulta a los autores de llamada hacer un buen trabajo en cuanto al tratamiento y la recuperación de errores. El mecanismo de excepciones de Java se ha configurado para facilitar a los autores de llamada la anticipación de qué puede salir mal y escribir código para administrar cada circunstancia de excepción específica. Declarar que un método lance una forma genérica de excepción frustra este sistema.

Ejemplo: el método siguiente lanza tres tipos de excepciones.

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

Aunque pueda parecer que es más organizado a la hora de escribir

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

al hacerlo se puede alterar la capacidad del autor de llamada para comprender y administrar las excepciones que se producen. Es más, si una revisión posterior de doExchange() introduce un nuevo tipo de excepción que debería tratarse de forma diferente a las excepciones anteriores, no hay una forma fácil de exigir este requisito.

Habitualmente, los programadores obtienen NullPointerException bajo tres circunstancias:

1. El programa contiene una anulación de referencia de puntero nulo. Obtener la excepción resultante era más sencillo que solucionar el problema subyacente.

2. El programa inicia de forma explícita una NullPointerException para señalar una condición de error.

3. El código es parte de un test de aprovechamiento que proporciona una entrada inesperada en las clases que se están probando.

De estas tres circunstancias, solo la última es aceptable.

Ejemplo: El código siguiente obtiene de forma errónea una NullPointerException.

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

Habitualmente, los programadores obtienen NullReferenceException bajo tres circunstancias:

1. El programa contiene una anulación de referencia de puntero nulo. Obtener la excepción resultante era más sencillo que solucionar el problema subyacente.

2. El programa inicia de forma explícita una NullReferenceException para señalar una condición de error.

3. El código es parte de un test de aprovechamiento que proporciona una entrada inesperada en las clases que se están probando.

De estas tres circunstancias, solo la última es aceptable.

Ejemplo: el siguiente código obtiene de forma errónea una NullReferenceException.

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

Una instrucción return dentro de un bloque finally provocará que todas las excepciones que se puedan lanzar en el bloque try se descarten.

Ejemplo 1: en la siguiente cita de código, la MagicException lanzada por la segunda llamada para doMagic con true transferido a ella nunca se entregará al autor de llamada. La instrucción return dentro del bloque finally provocará que la excepción se descarte.

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

}

Los errores ThreadDeath solo deben filtrarse si una aplicación tiene que limpiar después de finalizar de forma asíncrona. Si se filtra un error ThreadDeath, es importante que se vuelva a lanzar para que el subproceso finalice realmente. El propósito de lanzar ThreadDeath es detener un subproceso. Si ThreadDeath es absorbido, puede impedir que un subproceso se detenga y dé lugar a un comportamiento inesperado, puesto que quien haya lanzado originalmente ThreadDeath espera que el subproceso se detenga.

Ejemplo 1: el código siguiente filtra ThreadDeath, pero no lo vuelve a lanzar.

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

En Java, los bloques finally siempre se ejecutan después de su bloque try-catch correspondiente y se utilizan frecuentemente para liberar recursos asignados, como controladores de archivos o cursores de base de datos. Lanzar una excepción en un bloque finally puede derivar el código de limpieza crítico, puesto que la ejecución normal del programa se interrumpirá.

Ejemplo 1: en el código siguiente, la llamada para stmt.close() se deriva cuando se lanza la FileNotFoundException.

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

Las vulnerabilidades de excepción no administradas se producen cuando:

1. Se arroja una excepción.

2. La excepción no se administra correctamente antes de que salga de la página actual.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta función no puede tener nunca errores" y "no importa si se produce un error en esta operación". Cuando un programador no puede detectar una excepción que puede arrojar una operación, implícitamente indica que está funcionando según uno de estos supuestos.

Las vulnerabilidades de excepción SSL no administradas se producen cuando:

1. Se lanza una excepción específica de SSL.

2. La excepción no se administra explícitamente.

Las excepciones específicas de SSL javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLKeyException y javax.net.ssl.SSLPeerUnverifiedException transmiten errores importantes relacionados con una conexión SSL. Si estos errores no se administran explícitamente, la conexión puede dejarse en un estado inesperado y potencialmente inseguro.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos suposiciones dudosas que son fáciles de identificar en el código son "esta función no puede tener nunca errores" y "no importa si se produce un error en esta operación". Cuando un programador no puede detectar una excepción que puede arrojar una operación, implícitamente indica que está funcionando según uno de estos supuestos.