1

フレームワークが提供する例外を使用することは悪い習慣と見なされますか? 私はSpring JDBCを使用していますが、このIncorrectResultSizeDataAccessException例外を見つけました。これはまさに私が望んでいることです。リポジトリ層から投げます。リポジトリとサービス レイヤーは、私が Spring を使用していることを既に認識しています。

一般に、このような独自の例外を作成しますか、それともフレームワークが提供する例外が使用できる場合はそれに依存しますか?

4

5 に答える 5

2

自分のコードで Spring コードの依存関係を作成しません。実装を Spring に依存させることは 1 つのことです。サード パーティのフレームワークへの依存を強制する API を作成すると、API を介して実装の詳細が単純に流出します。

まず、ユース ケースに適合する標準の Java 例外があるかどうかを確認し、そうでない場合は、カスタム 例外を作成します。

于 2013-03-18T18:49:04.327 に答える
2

いくつかの理由から、独自に定義した例外を使用することに頼っています。

  • 一部のサードパーティ フレームワークと比較して、例外に対するライフ サイクル バージョン管理がはるかに優れています。
  • 必要な例外を使用するために、一部のサードパーティ フレームワークのバージョンに依存しないでください。
  • 独自の非チェックまたはチェック例外階層を設計でき、アプリケーションのニーズによって例外設計が決定されます (一部のサードパーティ フレームワークではありません)。
  • 例外コードを簡単にリファクタリングし、メソッドを追加/更新/削除できます。

私が見る唯一の欠点は、サードパーティのフレームワークの例外をアプリケーション固有の例外にラップしてしまう可能性があることです...

try
{
  //...do something...
}
catch(SQLException e)
{
  throw new MyAppException(e);
}
于 2013-03-18T18:57:49.527 に答える
1

それを使用することが実際に悪い習慣になる理由はわかりません。独自の例外を作成するよりも、既存の例外をスローすることをお勧めします (したがって、例外が発生した場合に、あなたや他の人がより簡単に理解できるようになります)。

于 2013-03-18T18:49:38.537 に答える
1

サービス層はすでに Spring を使用しているため、既存の Spring-JDBC 例外を使用することは合理的と思われます。最大の問題は、使用方法が Spring の使用方法と一致していない場合、混乱を招く可能性があることです。

Spring JDBC を使用している場合、既に Spring コードに依存しています。例外を再利用すると、例外処理がより均一に保たれます。

于 2013-03-18T19:05:58.760 に答える
0

これは意見の問題であり、プログラマーのスタック交換に適していると思います。しかし、IMO、それは大丈夫です。IllegalArgumentExceptionなどのJavaが提供する例外を除いて、私は常にそれを行っています。フレームワークも再利用してみませんか？

私が考えることができる欠点は、プロジェクトでSpringを置き換える場合、その例外を置き換える必要があるのは少し奇妙なことです。しかし、そもそもそうする可能性は低いと思います。

また、他のレイヤーは例外を処理する必要があるため、Springコードをそれらのレイヤーに公開します（パッケージ内の「spring」を含む例外をインポートする必要があるため）。これは欠点になる可能性があります。しかし、それは例外の再利用に対する議論というよりも、例外に対する議論かもしれません。

于 2013-03-18T18:46:56.003 に答える