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.