2013-03-05 15 views
6

私はデータアクセスオブジェクトにJavaメソッドを持っています。この非常に単純なメソッドは、2つの整数値をデータベースに挿入します。 SQLExceptionがスローされ、またはそれがリターンコードを介してユーザに通知し、その後、例外をキャッチし、ログインする必要があるときデータアクセスオブジェクト(DAO)のメソッドで例外をスローまたはキャッチする必要がありますか?

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

この方法、または、一般的に言えば、任意のDAOのメソッドは、例外をスローする必要がありますか? Springを使用するアプリケーションの正しいアプローチはどれですか?

+5

合意した「ベストプラクティス」はありません。 –

+0

@MattBall - 私はそれを確信しています。しかし、私はこれで新しいので、私はこれらの状況を解決する方法を説明する必要があります。 – Artegon

+0

実際、DAO例外を処理する最も一般的な方法は、いくつかのカスタムDAO例外クラスでそれらをラップすることです。 BalusCのこの非常によく普及しているチュートリアルを読んでください。他の人の中には、DAOの例外処理やその他の優れた実践について議論しています。[DAOチュートリアル - データレイヤー](http://balusc.blogspot.com/2008/07/dao-tutorial-data -layer.html) – informatik01

答えて

1

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

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

4

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

SQLExceptionをスローすると面倒ですが、すべてのメソッドで "例外をスロー"するか例外を摂取するだけで上位層になるでしょう。これらの選択肢のどちらも良いものではありません。

Springは元のSQLExceptionを取り込み、元のSQLExceptionを原因とするRuntimeExceptionのサブクラスをスローし、可能な限り多くの情報を提供しようとする例外トランスレータを提供します。ベンダーのエラーコードを使用して、スローする特定のサブクラスを決定します。 SpringのjdbcTemplatesのいずれかを利用する場合は、例外翻訳機能が使用されるため、データアクセスオブジェクトに例外をキャッチまたはスローする必要はありません。

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

+0

私は春を使います。これをSpring Frameworkでどのように解決するかについての情報を教えてください。 – Artegon

+2

@ user1315357ここから開始:http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/dao.html jdbcテンプレートを使用すると、例外翻訳にアクセスできます。 http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/jdbc.html –

+0

@ user1315357また、spring jdbcを使用してどのくらいのコードを保存することができるかについては、このチュートリアルを参照してください。 http://www.dzone.com/tutorials/java/spring/spring-jdbc-tutorial-1.htmlグーグルの "spring jdbc tutorial"はたくさんのものをもたらします。 –

1

私は、RuntimeExceptionではないDAOExceptionと呼ばれる新しい例外を作成し、この例外の処理をユーザーに強制します。例外を記述するDAOExceptionのメンバーとしてenumを使用する可能性があります内部例外としての内部例外)。

だから、スローされた例外は、次のようになります。

new DAOException(DAOException.TYPE.SQLE, e) 

及び方法saveHourMinはDAOExceptionをスローします。

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

一般的な例外を使用することをお勧めしますが、ランタイムではない理由は、例外を処理するためにオプションではないためです。誰でもこのメソッドを呼び出すと、そのような問題が発生する可能性があることを認識し、関連する処理を提供する必要があります(新しいRuntimeExceptionをスローすることを意味する場合でも、神は禁じられます。経験則としては、RuntimeExceptionsを使わないでください。なぜなら、実行パスが不明確になるからです(「誰かが実行パスのどこかでこれをキャッチするか、アプリを殺すだろうから、それを放置しても大丈夫です」と聞こえません私には良いことに)。

関連する問題