2

アプリケーションで大量のカスタム例外が必要な場合でも、カスタム例外を定義してスローすることは良い習慣ですか?

  • EntityNotFoundException
  • EntityAlreadyExistsException
  • EntityNotUniqueException
  • EntityNotAddedException
  • EntityNotUpdatedException
  • EntityNotDeletedException
  • QuizOverException
  • クイズ期限切れの例外
  • TableAlreadyBookedException
  • EndDateMustBeGreaterThanStartDateException

これらのサンプルの例外名に名前を付けて、その目的をできるだけよく説明しようとしました。私が何を尋ねようとしているのか、彼らが考えを形成してくれることを願っています。

これらの例外だけで想像力を制限しないでください。アプリケーションの使用中に発生する可能性のあるすべてのものです。CRUD とビジネス例外の両方を検討してください。

例外のスローとキャッチは、パフォーマンスの点で高価なプロセスであることは知っていますが、アプリを開発するためのより洗練された方法を提供しませんか?

  • EntityNotFoundExceptionエンティティが null かどうかを確認するには、if ステートメントを記述する代わりに、をスローした方がよいのではないでしょうか。
  • EntityAlreadyExistsException指定された Id を持つエンティティが既に存在するかどうかを確認するメソッドを呼び出す追加の if ステートメントを記述する代わりに、をスローする方がよいのではないでしょうか?
  • EntityNotAddedExceptionトランザクションが成功したかどうかを示す bool 型の戻り値をチェックするのではなく、a をスローした方がよいのではないでしょうか。オブジェクトを返したい場合はどうすればよいでしょうか?

答えは「使うべきではなくEntityNotFoundException、代わりにnullかどうかを確認してください。しかし、使用する必要がありますEntityAlreadyExistsException」、「聖杯はありません」のようなものになると思います。

これを行うエレガントな方法は何ですか？

4

4 に答える 4

5

例外は例外的な状況を表すものであることを心に留めておいてください。すべての質問は、実際には -それは依存します。

特定の例外をいつどこでスローするかのコンテキストによって、それが理にかなっているかどうかが自然に決まります。たとえば、存在するはずなのに存在しないエンティティを取得しようとする場合、例外的な状況が発生したため、 をスローするEntityNotFoundExceptionことが適切であると見なされます。一方、新しいエンティティを作成する前にエンティティが既に存在するかどうかを確認している場合は、エンティティが存在する可能性も存在しない可能性もあることがわかっているため、実際には例外的な状況ではないと主張できます。

前述したように、例外をスローするかどうかは、状況のコンテキストとアプリケーションの性質に大きく依存しますが、実行したくないことの 1 つは、例外を使用してプログラム フローを制御することです。

例外とビジネス ロジックのどちらを使用するのが適しているかを区別するには、単に「この特定の状況は有効か?」、つまり「アプリケーションがこの状態になっても問題ないか?」と自問してください。答えが「はい」の場合は、ロジックを使用してアプリケーションのフローを制御し、状況に対処します。それ以外の場合は、 をスローしExceptionてプログラム フローを効果的に中断し、何かが正しくないことをユーザーに通知します。

于 2013-07-31T12:22:35.330 に答える
1

ソフトウェア開発のほとんどすべてと同様に、一般的なルールまたはベスト プラクティスが与えられた場合、スキルはそれをいつ、どのように適用するかを知っています。

インターフェイスにプログラムする必要がありますか? はい！作成するすべてのクラスに対応するインターフェイスを実装させ、その抽象化に対してのみプログラムする必要がありますか? それはできますが、非常に単純なアプリケーションを作成するには、かなりの年月がかかり、生産性が大幅に低下します。

単一の責任 - それは良いことですか? はい！私が書いたすべてのクラスには、1 つだけの責任がありますか。いいえ - 部分的にはプログラマーとしての私自身の失敗によるものですが、単一メソッドのクラスが大量に発生し、コード ベースが手に負えないほど切り離されてしまうこともありました。

それでは、エラー処理に移りましょう。

まず、 James の回答に対するあなたのコメントを見て、エラー コードの使用と例外処理の使用は、アプリケーションでのエラー処理の 2 つの異なるモデルを表し、原則としてそれらを混在させてはならないことを明確にします。

例外処理を使用していると仮定して、次の引数を作成します。

なぜ例外をスローするのですか?

何か問題が発生したため、例外をスローします。ある時点でシナリオが発生すると予想している場合、それはアプリケーションのフロー内にあるため、例外ではありません。したがって、をスローするExceptionことは適切ではありません!

この引数では、最上位クラス以外のものをスローしてもほとんど意味がありExceptionません。他の例外は、このシナリオを予見し、追加のメタデータを例外に添付できたことを意味するためです。

なぜ例外を処理するのですか?

例外をスローしたので、アプリケーションを一貫した状態に復元することを目的として、どこかで誰かがそれに対処することを期待しています。ただし、例外が本当に例外的である場合、どの状態が破損しているかを知る方法がないため、例外処理は無駄です。

これは少し行き過ぎではありませんか？

これは、まさにサービス指向アーキテクチャでエラー処理がどのように機能するかです。堅牢なサービスは、例外が発生したときに何が起こったのかを明らかにするべきではありません (これはセキュリティ違反であり、サービスとクライアントの間の結合をもたらします)。クライアントが知る必要があるのは、何か悪いことが起こったことだけです。

ただし、私たちはオブジェクト指向環境で作業していると推測しています。そこでは、実装とその消費者との間の結合の程度が少し高くなることを受け入れる準備ができています。これが重要な点です。例外に関する詳細な情報を公開する例外階層を導入することで、アプリケーション内の結合が増加します(消費者は、スローされる可能性のあるすべての例外について詳細な知識を持っている必要があります)。

ソフトウェアでは、疎結合のコード ベースを目指して、保守と拡張を容易にしています。例外に対するSOAアプローチと、あなたが質問で説明したものとの間には、間違いなく幸せな中間点があります-スイートスポットが開発者のスキルであることがわかります。

于 2013-08-29T13:08:20.937 に答える