15

私は Java SE7 の新機能をチェックしており、現在この時点にいます:

http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html

このステートメントに出くわしたとき、複数のキャッチ機能に関して：

注: catch ブロックが複数の例外タイプを処理する場合、catch パラメーターは暗黙的に final になります。この例では、catch パラメーター ex は final であるため、catch ブロック内でそれに値を割り当てることはできません。

キャッチされた例外を処理する古典的なケースでは、キャッチされた例外が最終的なものではないことに気づきませんでした。

そもそもなぜそれが良いことなのだろうか？キャッチされた例外を再スローするか、メッセージをログに記録する前に、本質的に変更することはお勧めできませんか? 例外を作成するのはトローイングメカニズム次第ではないので、それが何をすべきかを正確に表しますか?

catch ブロックで例外が変更されているのを見たことがありませんが、誰かがその利点を指摘できますか?

4

4 に答える 4

4

メソッドの引数とほぼ同じです。

通常、それらを変更することはなく、多くのfinal人が(実際にそれらの前に書き込むかどうかはfinal議論の問題です)として扱われるべきであることに同意します。

ただし、必ずfinal.

個人的には、catch ブロックの例外参照を変更する正当な理由がないことを知っています。

于 2013-06-06T10:39:52.213 に答える
3

catch古典的な句の例外を変更するための説得力のあるユースケースは思いつきません。とはいえ、それは禁止されるべきだという意味ではありません。特に、パラメーター変数を変更できることを考えると。これが気になる場合は、例外変数を と宣言するオプションがありますfinal。

一方、複数例外キャッチで変更を許可すると、次のような本当に奇妙で紛らわしいコードが作成される可能性があります。

  catch (IOException | NullPointerException ex) {
      ...
      ex = new IllegalArgumentException(...);
  }

この場合に制限を追加したとき、設計者はそれを念頭に置いていたと思います。

いずれにせよ、これが Java 言語の定義方法であり、私たちが対処しなければならないものです。新しい言語を設計して実装するつもりでない限り、明らかな矛盾について議論することにはあまり意味がありません。

于 2013-06-06T11:18:33.167 に答える
0

例外ベースのエラー処理の背後にある考え方は、可能であれば、適切な抽象化レベルで各エラーを回復する必要があるというものです。このようなエラー回復には、例外が実際に処理される場所では直接利用できない情報が必要になる場合があります。このため、例外をキャッチし、関連情報を追加して再スローするか、より適切なクラスの新しい例外オブジェクトの原因として設定すると便利な場合があります。

于 2013-06-06T11:34:09.683 に答える