@PostConstructドキュメントでは、注釈付きメソッドについて次のように述べています。
「メソッドはチェックされた例外をスローしてはなりません。」
たとえば、そのようなメソッドでスローされる可能性のあるIOExceptionをどのように処理しますか?それをRuntimeExceptionでラップし、ユーザーにオブジェクトの初期状態の誤りを心配させますか?または、@ PostConstructは、依存関係が注入されたオブジェクトを検証および初期化するための間違った場所ですか?
@PostConstructドキュメントでは、注釈付きメソッドについて次のように述べています。
「メソッドはチェックされた例外をスローしてはなりません。」
たとえば、そのようなメソッドでスローされる可能性のあるIOExceptionをどのように処理しますか?それをRuntimeExceptionでラップし、ユーザーにオブジェクトの初期状態の誤りを心配させますか?または、@ PostConstructは、依存関係が注入されたオブジェクトを検証および初期化するための間違った場所ですか?
はい、ランタイム例外でラップします。できれば、より具体的なIllegalStateException.
init メソッドが失敗した場合、通常、アプリケーションは起動しないことに注意してください。
一般に、Bean の 1 つが例外をスローしたときにアプリケーションの起動に失敗することが必要な場合、または予想@SneakyThrowsされる場合は、Lombok の.
正しく使用すると、非常に便利で簡潔になります。
@SneakyThrows
@PostConstruct
public void init() {
// I usually throw a checked exception
}
ここでその長所と短所について議論している最近の記事があります。
楽しみ!
そのようにソフト化された例外を使用して、実質的に RuntimeException でラップします: https://repl.it/@djangofan/SoftenExceptionjava
private static RuntimeException softenException(Exception e) {
return checkednessRemover(e);
}
private static <T extends Exception> T checkednessRemover(Exception e) throws T {
throw (T) e;
}
次に、使用法は次のようになります。
} catch (IOException e) {
throw softenException(e);
//throw e; // this would require declaring 'throws IOException'
}