問題タブ [checked-exceptions]

persistence.xml ファイルで構成されたデータソースで JPA を使用します。

アプリケーションのデプロイ後にデータベース名が存在しなくなった場合、またはデプロイ後にパスワードが変更されたためにパスワードが間違っている場合 (通常はデータベース接続の失敗)、スローする必要がある例外 (Checked Exception) は何ですか?

私のJavaプロジェクトの例外 PersistenceException でそれをキャッチすることに成功していないため...

本当にありがとうございました。

いくつかの背景、そしていくつかの質問。

インターフェイス（またはクラス）が、そのメソッドがスローする可能性のある（チェックされた）例外のタイプでジェネリックである可能性があることを最近発見しました。例えば：

ポイントは、後でこれをインスタンス化し、たとえばメソッドIOExceptionを呼び出したrun場合、コンパイラーは、それをキャッチするかIOException、スローされたものとしてマークする必要があることを認識していることです。さらに良いことに、Xが だった場合は、RuntimeExceptionそれを処理する必要はまったくありません。

上記のインターフェイスを使用した不自然な例を次に示しますが、これは基本的にコールバックであり、非常に一般的なはずです。

特定のチェック済み例外で独自の特定のメソッドを実行するために、一般的なユーティリティ メソッド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。)

throwこのステートメント (より複雑なコードから抽出されたもの) がコンパイルされることに偶然気付きました。

短いながらも幸せな瞬間、私はチェック例外が最終的にすでに死ぬことを決定したと思っていましたが、それでもこれには満足しています:

ブロックは空である必要はtryありません。そのコードがチェックされた例外をスローしない限り、コードを持つことができるようです。それは理にかなっているように思えますが、私の質問は、言語仕様のどの規則でこの動作が説明されているのでしょうか? 私が見る限り、§14.18 throw ステートメントは明示的に禁止しています。これは、式の型がtチェック済み例外であり、キャッチされていないか、スローされるように宣言されていないためです。(?)

TL;DR で申し訳ありませんが、説明が必要なように感じます。そうしないと、誤解される可能性があります。

RuntimeException をスローすることがあると予想される (通常は外部の) コードを呼び出すメソッドがあり、InterruptedException または ExecutionException をスローできるフューチャーを使用し、返された値の順序付けられたセットを例外がスローされるまで呼び出し、スローされた例外。動作するものを書きましたが、残念なことに、コードの見た目が間違っているように感じます。私が本当に望んでいるのは、マルチキャッチをより一般的な概念にすることです。これにより、次のような非常にクリーンなコードで問題を解決できます。

そして、外部コードへの呼び出しを行う方法をまとめます...

そしてその後

など。常に例外をすぐに再スローしたいことに注意してください。これは、誰がこれらの結果を使用して何をしたいかによって異なります。私は次のようなことをするかもしれません

もちろん、例外をキャッチして結果として返すのではなく、結果を生成する関数で例外をスローさせることもできます。これには 2 つの非常に大きな問題があります。これにより、例外が返されたときにセットを最新の状態にすることができます。例えば

2. 外部メソッド呼び出しを囲むコードが実行時例外をスローするとどうなりますか? 例外呼び出しが外部コードへの実際の呼び出しによるものか、それ以外のものかを区別する簡単な方法がありません! この設計を試みたときに、実際にこの問題に遭遇しました。コードは別の場所から IllegalArgumentException をスローし、私のコード処理はそれを SomeReturnType externalCodeCallGetSomeReturnValue(Bar bar) からスローされたかのように処理しました。これはコードの健全性の問題のように思えたので、このソリューションから離れました。

私が行った解決策は、例外を例外として保存することです。しかし、その型情報を失うのは嫌でした。追加のコード作業がない場合、何かがそれをスローしたい場合は、「throws Exception」を宣言する必要がありますが、これは良くありません。同様のコードの健全性の問題があります。この状況を処理する良い方法はありますか? 私がやりたいように動作させるために私が最終的にやったことは次のとおりです：

明らかに、これはかなり醜いです。コンストラクターがそのまま嫌いな場合は、例外を受け取る単一のコンストラクターに簡単に置き換えることができますが、型チェックが throwException() のランタイム呼び出しのみに弱まります。とにかく、よりうまく機能する代替手段はありますか？私はJDK 7で使用しているため、JDK 8の回答は興味深いものですが、私が取り組んでいるものは修正されません。

私は Java (主に数学、UI、グラフィックス) の経験が豊富org.w3c.domですが、JDBC のような API や、チェックされた実行時例外の処理に大きく依存している API を真剣に扱ったことはありません。したがって、これらの種類の API で動作する一連のメソッドを作成する場合、例外をすぐにキャッチするか、メソッドのシグネチャに追加して例外をフレームの上位レベルに伝播するか、例外をどう処理するかをどのように決定すればよいでしょうか。スタック、それらはすべてどこで処理されますか? これらのチェック済み例外でやりたいことは、エラーが発生するたびにエラーでアプリケーションを終了することだけのようです。