几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中，很容易发现两个令人怀疑的假设：“一是这个函数调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。”因此当程序员忽略条件时，这其实就表明了他们是基于上述假设进行的操作。

例 1：下列摘录的代码会忽略 CICS 事务期间可能发生的错误情况。

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

如果事务因为此错误情况而失败，程序会继续执行，就像什么都没有发生一样。程序不会记录任何有关这一特殊情况的依据，因而事后再查找这一异常就可能很困难。

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中，很容易发现两个令人怀疑的假设：“一是这个方法调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。”因此当程序员忽略异常时，这其实就表明了他们是基于上述假设进行的操作。

例 1：下面摘录的代码会忽略一个由 doExchange() 抛出的罕见异常。

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

如果抛出 RareException 异常，程序会继续执行，就像什么都没有发生一样。程序不会记录任何有关这一特殊情况的依据，因而事后再查找这一异常就可能很困难。

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中，很容易发现两个令人怀疑的假设：“一是这个函数调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。”因此当程序员忽略异常时，这其实就表明了他们是基于上述假设进行的操作。

例 1：下列代码忽略了在执行插入指令时可能抛出的一些异常。

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

由于该表不存在、未提供所需值或一些其他的原因，运行程序时可能会抛出异常。如果运行失败，我们就无法知道原因，因为该程序不会报告该失败或记录发生了哪种类型的失败。

多个 catch 块看上去繁琐，但使用一个“简约”的 catch 块捕获高级别的异常类（如 Exception），可能会混淆那些需要特殊处理的异常，或是捕获了不应在程序中这一点捕获的异常。本质上，捕获范围过大的异常与“Java 分类定义异常”这一目的是相违背的，随着程序的增加而抛出新异常时，这种做法会十分危险。而新发生的异常类型也不会被注意到。

示例：以下代码使用了同一方式来处理三种不同的异常类型。

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

其实，与其这样，还不如使用一个单独的 catch 块来处理这三种异常，如下所示：

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

但是如果修改 doExchange()，以抛出需要以某种不同的方式处理的新异常类型，则范围过大的 catch 块会阻止编译器指出这一情况（有新的异常抛出）。此外，新 catch 块也将处理那些来自于 RuntimeException 的异常，比如 ClassCastException 和 NullPointerException，而这些异常的发生是不在程序员的计划之内的。

声明一种可以抛出 Exception 或 Throwable 异常的方法，从而使调用者很难处理和修复发生的错误。Java 异常机制的设置是：调用者可以方便地预计有可能发生的各种错误，并为每种异常情况编写处理代码。同时声明：一个方法抛出一个过于笼统的异常违反该系统。

示例：以下方法抛出了三种类型的异常。

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

这样写看上去会显得更加紧凑

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

这样做会防碍调用者理解和处理所发生的异常。此外，如果 doExchange() 因为变更了代码，而引入了一个需要不同于之前异常处理方式的新型异常，则不能使用简单的方式来处理该要求。

程序员通常会在以下三种情况中捕获 NullPointerException：

1.程序包含一个 null 指针间接引用。捕获生成的异常比修复底层问题更容易。

2. 程序显式地抛出了一个 NullPointerException 异常来标记错误状况。

3. 该代码是测试代码的一部分，为正在测试的类提供了一个异常输入。

在上述三种情况中，只有最后一种是可以接受的。

示例：下列代码错误地捕获了一个 NullPointerException 异常。

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

程序员通常会在以下三种情况中捕获 NullReferenceException：

1.程序包含一个 null 指针间接引用。捕获生成的异常比修复底层问题更容易。

2. 程序显式地抛出了一个 NullReferenceException 异常来标记错误状况。

3. 该代码是测试代码的一部分，为正在测试的类提供了一个异常输入。

在上述三种情况中，只有最后一种是可以接受的。

示例：下列代码错误地捕获了一个 NullReferenceException。

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

finally 块中的返回指令会导致从 try 块中抛出的异常丢失。

例 1：在下列代码中，第二次调用 doMagic 方法，同时将参数 true 传递给该方法会导致抛出 MagicException 异常，该异常将不会传递给调用者。finally 块中的返回指令会导致异常的丢弃。

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

}

如果异步终止了应用程序后需要将其清除，则应仅捕获 ThreadDeath 错误。如果捕获了 ThreadDeath 错误，则将其重新抛出非常重要，因为这样该线程才真正地终止。抛出 ThreadDeath 的目的是终止线程。如果 ThreadDeath 被抑制，则它可以阻止线程停止并导致意外行为，因为代码最初抛出 ThreadDeath 的目的是希望停止该线程。

例 1：下列代码捕获了 ThreadDeath 但未将其重新抛出。

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

在 Java 中，finally 块通常在其相应的 try-catch 块之后执行，该块通常用于自由分配的资源，例如文件句柄或数据库指针。由于破坏了正常的程序执行，在 finally 块中抛出异常会绕过关键的清除代码。

例 1：在下列代码中，抛出 FileNotFoundException 时，将绕过对 stmt.close() 的调用。

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

以下情况中会出现 Unhandled Exception 漏洞：

1. 一个异常被抛出

2. 在异常离开当前页之前，未能对其进行适当地处理。

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

代码中两个容易识破的可疑假设是：“该操作从不会失败”和“如果该操作失败了也没关系”。如果程序员没有抓住某个操作抛出的异常，则间接地表明了他们是基于这些假设进行的操作。

未处理的 SSL 异常会在以下情况中发生：

1. 抛出特定的 SSL 异常。

2. 未显式地处理异常。

特定 SSL 异常 javax.net.ssl.SSLHandshakeException、javax.net.ssl.SSLKeyException 和 javax.net.ssl.SSLPeerUnverifiedException 都可以传达与 SSL 连接相关的重要错误。如果没有显式地处理这些错误，连接会被处于一种意想不到的、潜在不安全的状态。

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

代码中两个容易识破的可疑假设是：“该操作从不会失败”和“如果该操作失败了也没关系”。如果程序员没有抓住某个操作抛出的异常，则间接地表明了他们是基于这些假设进行的操作。