操作時に誤字があると、予期しない結果が生じる可能性があります。たとえば、+= を使用して変数に数値を加算しようとしたときに誤って =+ と記述しても、操作はまだ有効です。ただし、加算を実行する代わりに、変数が再初期化されます。

例 1 次のコードは、変数 numberOne に数値を加算することを目的としています。しかし、=+ 演算子を使用すると、実際には変数が 1 に再初期化されます。

uint numberOne = 1;

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

外部コントラクトへの呼び出しは失敗する可能性があり、その失敗が正しく処理されないと、呼び出し元コントラクト内で Denial of Service が発生する可能性があります。その場合、コントラクトを今後使用できなくなる可能性があります。

これは、外部呼び出しが loop ステートメント内で実行される場合に特に関係するほか、支払処理を扱う場合 (通常、ユーザーに資金をプッシュするのではなく資金を引き出してもらう方が良い場合) にさらに関係します。

例 1: 次のコードは、for loop ステートメントを使用して、関係するすべてのアドレスを send 外部呼び出しを使用して返金します。

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

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

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「このメソッドは決して失敗しない」、および「このメソッドコールが失敗するかどうかは重要ではない」です。プログラマが条件を無視する場合、プログラマはそれらの仮定のいずれかに基づいて作業していると暗黙のうちに認めています。

例 1: 次のコードの例では、CICS トランザクション中に発生する可能性のあるエラー条件が無視されます。

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

万が一トランザクションがこのエラー条件で失敗した場合、あたかも何もエラーが発生していないかのように、プログラムの実行が続行されます。プログラムは特別な状況を示す証拠を記録しないため、プログラムの動作を後で調べようとする場合に苛立ちを感じることもあります。

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

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

例 1: 次のコード部分では、doExchange() で稀に発生する例外を無視しています。

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

RareException が発生しても、プログラムは異常が発生しなかったかのように継続して実行されます。プログラムは特別な状況を示す証拠を記録しないため、プログラムの動作を後で調べようとする場合に苛立ちを感じることもあります。

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

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

例 1: 次のコードは、insert ステートメントの実行中に発生する可能性のあるいくつかの例外を無視しています。

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

テーブルが存在していないか、必須の値が指定されていないか、またはそれ以外の理由から、例外が発生する可能性があります。障害が発生した場合、プロシージャーはその障害を報告することも、どのタイプの障害が発生したのかを記録することもしないため、ユーザーは問題を知りようがありません。

複数の catch ブロックは繰り返しになりますが、Exception などの高レベルクラスをキャッチすることで catch ブロックを「簡略化」すると、特別な処理が必要な例外やプログラムのこの時点ではキャッチすべきでない例外が不明確になります。キャッチする例外があまりに広範にわたると、本質的に Java の入力例外の目的にそぐわなくなるだけでなく、プログラムが新しいタイプの例外を発生させるようになり特に危険になります。新しい例外タイプは特に注意されません。

例: 以下のコード引用は 3 種類の例外を同じように扱います。

  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 ブロックは ClassCastException や NullPointerException などの RuntimeException からの例外も扱うようになります。

Exception または Throwable を発生させるメソッドの宣言は、コールする側がエラー処理やリカバリ作業を行うことを困難にします。Java の例外メカニズムは、呼び出し側が不正な内容を予期し特別な事情に対応するコードを書きやすいように設定されています。メソッドが一般形式の例外を発生することを宣言すると、このシステムを無効にします。

例: 次のメソッドは 3 種類の例外を発生します。

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

次のように書くと整然としているように思われますが、

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

発生する例外をコールする側が理解して処理しにくくなります。さらに、doExchange() の今後の版で、従来の例外とは異なる方法で扱うべき新しいタイプの例外が導入された場合、この要件の遵守が困難になります。

プログラマは一般に次の 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 つの疑わしい仮定は、「この操作は決して失敗しない」、および「この操作が失敗するかどうかは重要ではない」です。プログラマが操作で発生する可能性のある例外を認識できない場合、プログラマはそれらの仮定のいずれかに基づいて作業していると暗黙のうちに認めています。