21

チェック例外である合理的な理由を考えられる人SQLExceptionはいますか?

はい、クエリに構文エラーがある可能性があります
はい、接続が切断された可能性があります はい
、権限の問題がある可能性があります
その他、何とか何とか何とか

しかし、ほぼ 100% の場合 (本番環境で実行している場合)、問題はありません。

問題が発生した場合、呼び出し元のコードは回復するために何もできないため、チェックを外す必要があります。

try catchJDBC を使用するプロジェクトに関与したことのある人なら誰でも証明するように、チェックされると、コード全体に機能的なブロックが大量に作成されます。コードの混乱は重大です。

SQL の難解な性質のため、SQLException を受け取る可能性がある無数の理由とその複雑さは、例外が一時的なネットワークの問題によって引き起こされない限り、基本的に回復できないことを意味しますが、それでも同期呼び出しではとにかく沈んでしまいますネットワークの問題が解決するのを無期限に待つことはできないため、トランザクションを失敗させる必要があります。

通常、SQL の呼び出しは次のようになります。

try {
    // make some SQL call(s)
} catch {SQLException e) { 
    // log the exception
    return; // and give up
}

そのようなコードには何の価値もありません。回復するためにできる合理的なことは何もありません。実行時例外をバブルアップさせることもできます。つまり、SQLException は実行時(未チェック) 例外にする必要があります。

4

4 に答える 4

2

チェック済みと未チェックのジレンマには、いくつかのアプローチがあります。呼び出し元のコードが例外から回復できるかどうかを確認することは 1 つのアプローチですが、これは同意しますSQLExcptionが、チェックされた例外である理由を説明していません。

Martin Fowler が著書 "Refactoring" で提供している別の方法では、例外が発生する可能性のあるチェックを行うのは、呼び出し元または呼び出されたメソッドの責任であるかどうかを確認することを提案しています。

呼び出されたメソッドを呼び出す前に、呼び出し元のメソッドがチェックを実行する必要がある場合(たとえば、引数が null でないことを確認するなど)、このチェックが行われていない場合は、明らかにプログラミング エラーであり、呼び出されたメソッドは未チェックの例外をスローする必要があります。

チェックを行うのが呼び出されたメソッドの責任である場合、このメソッドのみがそのようなチェックを実行する方法を知っているため、呼び出されたメソッドからスローされた例外をチェックする必要があります。

このクラスだけが知ることSQLExceptionができると思います：

  • これはデータベースに依存するため、クエリに構文エラーがあります
  • 接続が切れました
  • 許可の問題があります
于 2013-05-14T12:59:02.967 に答える
2

理由の 1 つは、メソッドが行うことの抽象化レベルと一致する例外をメソッドがスローする必要があることです。

したがって、データベースから情報をロードするメソッドはSQLException、 ではなく、ResourceNotFoundExceptionまたは を発生させる必要がありResourceUnavailableExceptionます。

チェックを作成するSQLExceptionことは、開発者が例外をキャッチして、この新しいレベルの抽象化でラップするように強制する方法です。

この引数は、Joshua Bloch による「Effective Java Second Edition」から引用されています (項目 61: 抽象化に適した例外をスローする)。

于 2013-05-14T13:07:32.410 に答える
1

例外をキャッチすると、例外的な状態から回復することができますが、それ以外のこともできます。

実行時に問題を修正するためにできることはあまりないという点で、SQLException から回復することはできませんが、できることはいくつかあります。

  • デバッグ情報の例外をログに記録します
  • トランザクションをロールバックする

より高いレベル (または視点によってはより低いレベル) で常に例外をログに記録できますが、デバッグ時とコードのレビュー時の両方で、セマンティック値が失われます。

次のようなことをすると:

try { ... }
catch(SQLException e) 
{ 
    SomeLogger.log(...);
    rollback();
    throw e;
}

後でこのコードに戻ると、コードを頭の中で解析して失敗する可能性があるかどうかを判断しなくても、try のコードが失敗する可能性があることがすぐにわかります。

もう 1 つできることは、データベース リソースが解放されていることを確認することです。

于 2013-05-14T13:38:12.117 に答える