0

重複の可能性:
Java のチェックされていない/チェックされた例外の明確化

Java でのチェック例外と非チェック例外の議論について読んでいます。違いは知っていますが、どちらを選択するかは完全にはわかりません。本当に選択肢はありますか？チェック例外の可能性がある場合に備えて、java は try catch の使用を強制しません。非チェック例外のみを使用してアプリケーションを実装する方法、そのようなアプリケーションでチェック例外が発生する可能性がある状況にどのように対処するか。チェックされた例外をチェックされていない例外に変換する方法に関するコードサンプルを使用して、これを解決してくれる親切な人がいれば、それは素晴らしいことです:)

4

2 に答える 2

0

チェック例外は、発生してはならない予期しない動作 (0 による除算など) ではなく、発生する可能性があり、プログラマーがそれらを管理する必要がある状況を表す状況でスローされることを意図しています。

これは非常にうまく機能する Java 言語と Java API の設計です。これは、処理すべき特別な状況につながる可能性のある機能を提供する API を使用するときに、何を気にする必要があるかを常に知っているためです。

チェックされた例外について忘れるポイントはわかりません。もちろん、例外を発生させる可能性のあるすべてをカプセル化して、何が起こっているかを内部的に管理し、チェックされていない（カスタム）例外をスローするだけで済みますが、これらの問題を気にする必要がありますとりあえず。

私が見ることができる唯一の安全なアプローチは次のようなものです：

class UncheckedFileNotFoundException extends RuntimeException {
  ..
}

class Foobar {
  public static void method(String path) {
    try {
      FileReader reader = new FileReader(path);
    }
    catch (FileNotFoundException e) {
      // code;
      throw new UncheckedFileNotFoundException();
    }
  }
}

しかし、これでは問題は解決しません。ファイルが見つからない場合、呼び出し元はそれに応じて何かを行い、例外を無視するか、メソッドが例外をスローする可能性があるという事実を隠す必要があります (商品がないため)throws FileNotFoundExceptionメソッド署名で）何も改善しません。

于 2013-01-05T02:27:05.293 に答える
0

JDK など、使用するライブラリに組み込まれているチェック済み例外を変更するオプションはありません。

ただし、必要に応じて、それらをラップして、チェックを外して再スローすることができます。それを試行/キャッチする必要があるメソッドの範囲への影響を最小限に抑えます。

また、作成したすべてのカスタム例外を拡張することができますRuntimeException。

于 2013-01-05T02:10:09.647 に答える