10

データ アクセス オブジェクトに Java メソッドがあります。この非常に単純なメソッドは、データベースに 2 つの整数値を挿入します。

public void saveHourMin(int hour, int min) throws SQLException{
psInsert.setInt(1, hour);
psInsert.setInt(2, min);
psInsert.executeUpdate();
}

このメソッド、または一般的に言えば、任意の DAO メソッドは、SQLException がスローされたときに例外をスローする必要がありますか?それとも、例外をキャッチしてログに記録し、リターン コードを介してユーザーに通知する必要がありますか? Spring を使用するアプリケーションの正しいアプローチはどれですか?

4

3 に答える 3

6

呼び出し元が一貫してリターン コードをチェックすることを期待することはできません。例外をスローしたほうがよいでしょう。

SQLException をスローすると、面倒になります。おそらく、すべてのメソッドに「例外をスローする」を追加するか、例外を食べるだけで、より高いレイヤーになります。これらの代替案はどちらも良いものではありません。

Spring が行う方法は、元の SQLException を取り込んで、元の SQLException を原因として含む RuntimeException のサブクラスをスローする例外トランスレーターを提供し、ベンダー エラー コードの使用を含め、エラーに関するできるだけ多くの情報を提供しようとすることです。どの特定のサブクラスをスローするかを決定します。Spring の jdbcTemplates のいずれかを利用すると、例外変換機能が得られるため、データ アクセス オブジェクトに例外のキャッチまたはスローを含める必要はありません。

Spring を使用したくない場合は、DAO 内で SQLException をキャッチし、元の SQLException を原因として含めて RuntimeException をスローできます。ほとんどの SQLExceptions に対してできることは何もありません。すばやく失敗して例外をログに記録したいだけです。

于 2013-03-05T20:30:50.227 に答える
1

私はノーと言うでしょう。SQLException をキャッチしてから、RuntimeException または子孫の場合は 1 つをスローします。データ アクセスの例外でアプリケーションを汚染したくありません。たとえば、GUI レイヤーで SQLExceptions をキャッチするべきではありません。リターン コードに基づいてアプリケーションを構築することもありません。

RuntimeException をスローすることで、呼び出し元に強制的にキャッチさせることもありません。

于 2013-03-05T20:21:09.290 に答える
1

RuntimeException ではない DAOException という新しい例外を作成し、例外を記述する DAOException のメンバーとして列挙型を使用して、メソッドのユーザーにそのような例外を処理するように強制します (おそらく、内部に実際の例外を内部例外）。

したがって、スローされた例外は次のようになります。

new DAOException(DAOException.TYPE.SQLE, e)

メソッド saveHourMin は DAOException をスローします。

このようにして、あらゆる種類の問題が発生した場合、それらはすべて同じ種類の例外の下にあり、異なるものを処理する必要はありません。

ランタイムではなく一般的な例外を使用することをお勧めする理由は、例外を処理するためにオプションにしたくないからです。このメソッドを呼び出す人は誰でも、そのような問題が発生する可能性があるという事実を認識し、適切な処理を提供する必要があります (それが新しい RuntimeException をスローすることを意味する場合でも、神は禁じられていますが、今は彼ら次第であり、彼らの決定です)。一般的な経験則として、実行パスが不明確になるため、RuntimeExceptions の使用は避けます (「誰かがおそらく実行パスのどこかでこれをキャッチするか、アプリを強制終了するので、手放しても問題ありません」とは聞こえません)。私にとって良いことです）。

于 2013-03-05T20:35:59.713 に答える