3

以下のコードが理にかなっていることはわかっています。

try { ... }
catch (FileNotFoundException exc) { ... }
catch (IOException exc) { ... }

しかし、 throws 句でこれらの親と子の例外を宣言することは意味があるのでしょうか?

次のコードがあるとします。

public void doSomething() throws FileNotFoundException, IOException { ... }

FileNotFoundExceptionのサブクラスであることは誰もが知っていIOExceptionます。これに反対して、そのように宣言することは、何らかの方法（読みやすさ、パフォーマンスなど）で理にかなっていますか？

public void doSomething() throws IOException { ... }
4

2 に答える 2

6

throwsJava コンパイラの場合、サブクラスが句に含まれるかどうかは問題ではありません。これは、スーパークラスの例外がそれをカバーするためです。

ただし、ドキュメントの目的では重要です。メソッドの呼び出し元は、サブクラスの例外 ( など) をスローして、別の方法で処理できることを知りたい場合がありますFileNotFoundException。

try {
    doSomething();
}
catch (FileNotFoundException e) {
    System.out.println("File not found!");
}
catch (IOException e) {
    System.out.println("An I/O error has occurred: " + e.getMessage());
}
于 2014-08-15T16:22:29.067 に答える
1

サブクラスの例外が最初に指定されている限り、両方の例外をキャッチすることが理にかなっている場合があります（そうしないと、コンパイルさえしないと思います）。関心のある特定の例外を、より一般的な例外とは異なる方法で処理できます。

たとえば、ソケットから読み取るコードがあります。読み取るものが何もない可能性があるため、これはブロッキング読み取りであり、タイムアウトを設定しました。だから捕まえSocketTimeoutExceptionて何もしない。一方、他IOExceptionの s (IOExceptionの間接的なスーパークラスであるSocketTimeoutException) を取得した場合、ソケットからの読み取り中に実際にエラーが発生したため、例外がスローされます。

    catch (SocketTimeoutException ignEx) {
// -- ignore exception, as we are expecting timeout exceptions because
// -- there might be nothing to read
    }
    catch (IOException ioEx) {
      throw new SomeException (...);
    }

メソッド シグネチャで両方を宣言する場合、throws句で両方を宣言する必要はありませんが、JavaDoc コメントで両方の例外を文書化し、それぞれが適用される条件を記述すると、メソッドのユーザーにとって便利です。投げられます。

于 2014-08-15T16:19:43.853 に答える