(Unchecked Exception) を宣言することの利点は何ですか? メソッド シグネチャに沿って例外をスローします。
public void testRuntimeEx()throws RuntimeException{
if(1==1){throw new RuntimeException()}
}
//Caller method
public void testCaller(){
// not necessery to handle even caller does not known which RuntimeException might be throws then what is the benefit throws clause with method signature
testRuntimeEx();
}
特に一般的な RuntimeException を使用せず、IllegalArgumentException、UnsupportedOperationException、IndexOutOfBoundsExceptionなどのより具体的なものを使用し、それがいつ発生するかについて JavaDoc を追加する場合は特に、ドキュメントとして機能します。
ただし、コード スニペットの例では、かなり無意味です。
この宣言は、このコードを使用する開発者にとって、RuntimeException をスローするシグナルです。でもいい匂いじゃない。
投稿した PS コードはコンパイルされません:
throw RuntimeException
これは正しい投げではありません。
利点は、通常、呼び出し元が例外とは関係がないことです。それをキャッチし、他の例外でラップして、再度スローします。または、代わりに、throwsキーワードを使用して例外を宣言し、例外の場合、この型に対して透過的になります。
説明されている状況は、通常、ビジネス コードを記述し、すべての例外を処理する集中化された場所を 1 か所に持つアプリケーションの典型的な状況であると言えます。API では正しくありません。たとえば、SSH を実装するライブラリを使用しているIOException場合、何か問題が発生したときにライブラリがスローする (またはさらに特化した例外をスローする) ことを期待しています。
カスタムのチェックされていない例外をスローすると、システム例外をキャッチするよりも意味があり、チェックされていない例外も強制的にキャッチされません。