いくつかの背景、そしていくつかの質問。
インターフェイス（またはクラス）が、そのメソッドがスローする可能性のある（チェックされた）例外のタイプでジェネリックである可能性があることを最近発見しました。例えば：
interface GenericRunnable<X extends Exception> {
void run() throws X;
}
ポイントは、後でこれをインスタンス化し、たとえばメソッドIOExceptionを呼び出したrun場合、コンパイラーは、それをキャッチするかIOException、スローされたものとしてマークする必要があることを認識していることです。さらに良いことに、Xが だった場合は、RuntimeExceptionそれを処理する必要はまったくありません。
上記のインターフェイスを使用した不自然な例を次に示しますが、これは基本的にコールバックであり、非常に一般的なはずです。
public <X extends Exception> void runTwice(GenericRunnable<X> runnable) throws X {
runnable.run(); runnable.run();
}
...
public myMethod() throws MyException {
runTwice(myRunnable);
}
特定のチェック済み例外で独自の特定のメソッドを実行するために、一般的なユーティリティ メソッドrunTwice(おそらく外部ライブラリで定義されている) を呼び出しています。どの特定のチェック済み例外がスローされる可能性があるかについての情報は失われません。
別の方法は、メソッドとメソッドのthrows Exception両方で単純に使用することでした。これにより、インターフェースの実装が制限されることはありませんが、チェック例外の利点が失われます。または、チェックされた例外の利点が失われ、実装が強制的にラップされる可能性もありました。Runnable.runrunTwiceRunnablethrows
見たことがなかったのでthrows X、何か見落としているのかもしれません。さらに、コールバックの例が反論されることなく、チェックされた例外に対する引数として使用されているのを何度か見てきました。(この質問は、チェック済み例外の長所/短所には関心がありません。)
throws X一般的には良い考えですか？長所と短所は何ですか？使用している、または使用していないが、使用する必要がある例をいくつか挙げていただけますthrows Xか?
基本的に、もう少し洞察が欲しいです。次の例についてコメントしてください。
OutputStreamスローIOException(おそらくByteArrayOutputStream拡張可能GenericOutputStream<RuntimeException>)Callable/Future.getコモンズプール
borrowObject/makeObject
(編集後、振り返ってみると、これらを別の方法で設計することができたかどうか、またはすべきであったかどうかは尋ねていません。むしろ、throws Xよりも優れているでしょうthrows Exception。)