プログラマは一般に次の 3 つの状況で NullPointerException をキャッチします。

1.プログラムが NULL ポインタ間接参照を含む場合。この結果発生した例外のキャッチは根本問題を解決するより簡単です。

2. プログラムがエラー状況を知らせるために明示的に NullPointerException を発生させる場合。

3. コードが、テスト中のクラスに予期しない入力をするテストハーネスの一部である場合。

これらの 3 つの状況のうち、認められるのは 3 番目の状況だけです。

例: 次のコードは NullPointerException を誤ってキャッチしています。

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

プログラマは一般に次の 3 つの状況で NullReferenceException をキャッチします。

1.プログラムが NULL ポインタ間接参照を含む場合。この結果発生した例外のキャッチは根本問題を解決するより簡単です。

2. プログラムがエラー状況を知らせるために明示的に NullReferenceException を発生させる場合。

3. コードが、テスト中のクラスに予期しない入力をするテストハーネスの一部である場合。

これらの 3 つの状況のうち、認められるのは 3 番目の状況だけです。

例: 次のコードは NullReferenceException を誤ってキャッチしています。

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

finally ブロック内部に return ステートメントがあると、try ブロックで発生する例外が破棄される原因となります。

例 1: 次のコードでは、doMagic への 2 番目のコールによって発生する MagicException、およびそのとき渡される true は、コールする側には渡りません。finally ブロック内の return ステートメントは、例外を破棄させます。

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. 現在のページを抜ける前に、この例外が適切に処理されない。

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「この操作は決して失敗しない」、および「この操作が失敗するかどうかは重要ではない」です。プログラマが操作で発生する可能性のある例外を認識できない場合、プログラマはそれらの仮定のいずれかに基づいて作業していると暗黙のうちに認めています。

次の場合に、SSL 例外の未処理の脆弱性が発生します。

1. SSL 特有の例外が発生する。

2. 例外が明示的に処理されない。

SSL 特有の例外 javax.net.ssl.SSLHandshakeException、javax.net.ssl.SSLKeyException、および javax.net.ssl.SSLPeerUnverifiedException はすべて、SSL 接続に関連する重要なエラーを伝達します。これらのエラーが明示的に処理されない場合、接続が予期しない状態で残されたままとなり、セキュリティ上安全ではない状態になる可能性があります。

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「この操作は決して失敗しない」、および「この操作が失敗するかどうかは重要ではない」です。プログラマが操作で発生する可能性のある例外を認識できない場合、プログラマはそれらの仮定のいずれかに基づいて作業していると暗黙のうちに認めています。