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

例 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() の今後の版で、従来の例外とは異なる方法で扱うべき新しいタイプの例外が導入された場合、この要件の遵守が困難になります。