4

私はプロセスがこのように進むアプリケーションに取り組んでいます

UI --> backend process --> result to UI.

私の Java コードでは、try-catch を使用して例外を処理しましたが、コードには非常に多くの繰り返し例外があり、異なるクラスで同じ例外をスローする可能性があり、可読性とコードの再利用が低下します。

そのため、異なるクラスで同じ例外をスローする代わりに、例外を整理して例外コードを再利用する必要があるように、例外処理戦略を実行することを計画しています。

これを行うための最良の例外処理手法を誰かに提案してもらえますか?

4

5 に答える 5

2

クライアントが使用する GUI があるため、クライアントは例外が発生したかどうかを知る必要があるため、例外を処理するのに最適な場所は最上層 (GUI と通信する層) になります。

スローされた例外をキャッチし、ログに記録してから再度スローすることもできます。

つまり、他のすべての下位レイヤーは例外をスローするだけです。

いくつかのカスタム例外を作成して、通常の例外の代わりに使用できます (つまり、SqlException をキャッチし、例外コード、クエリ文字列などの詳細を含む MyDBException をスローします)。

編集

また、例外を論理と機能の 2 つのカテゴリに分けることも検討します。

  1. 論理 - ユーザーが無効なユーザー名/パスワードでログインしようとした場合など、アプリケーション ロジックの問題。これらのエラーは通常、意図的にスローされ、作成したカスタム エラーになります。
  2. 機能 - アプリケーション自体の問題 (DB 接続など) が原因でスローされるすべての通常の例外

次に、各タイプを処理するための戦略を決定できます。論理的例外は特定のデータをユーザーに返し (無効なユーザー名/パスワード)、機能的例外は次のようなより一般的なメッセージを返します。問題が発生しました。サポートに連絡してください。

于 2012-08-06T09:53:35.907 に答える
1

このためのデザイン指向のアプローチを示したいと思います。

  1. 最初に「Martin Spamer」は正しいです。Checked 例外のみをキャッチする必要があるためです....しかし、非常に細かいレベルで....たとえば、InvalidCredentialException と AuthorizationException は、LoginException としてスロー/キャッチしないでください。そして、将来、これらのタイプを別の方法で処理するように求められますか??

  2. 第二に、UI ----> フロント層 ----> サービス層 -----> DAO 層があります。

ロジックは、

(i) フロント ティアは UI からリクエストを受け取り、フロント エンド ベースの検証/例外 (ログイン中の MissingUserNameException など) を処理します。すべてがOKであれば、リクエストをサービスレイヤーに転送します

(ii) サービスはビジネス ロジックを検証し、有効な場合は要求を処理します。そうでない場合は、フロントエンド層への適切なメッセージとともに例外をスローします

(iii) ただし、各サービス レベルの例外メッセージは、ユーザーの表示に適していない場合があります。したがって、フロント層の責任は、ビジネス例外をクライアントが読み取り可能な例外に変換することです

このアプローチには、別の追加の利点があります。いくつかのビジネス メソッドを Web サービスとして公開する必要があるという要件が発生したとします。そのため、いずれにせよサービスは公開されます。ここで、例外処理全体 (つまり、例外を適切なメッセージに変換する) ロジックをフロントエンド層に配置し、サービス層がそれらを完全に認識しない場合、サービス層のコードを再度リファクタリングする必要がある場合は混乱します (また、前段）。しばらくしてから、最前線のテクノロジが時代遅れになり、新しいテクノロジで例外処理ロジック全体を再コーディングする必要があるという別の状況が発生する場合があります。

つまり、サービス層はすべてのビジネス検証例外を認識し、適切なメッセージで処理する必要があります。例外を適切なメッセージで装飾した後、サービスが呼び出されたクライアント層に引き渡します。メッセージを表示し、必要に応じて他のメッセージで再び装飾するのは、クライアント層の責任です。このようにして、すべての層を独立した状態に保つことができます。

于 2012-08-08T07:03:57.543 に答える
-2

編集:元の回答は、他の質問でここに移動しました: https://stackoverflow.com/a/16172074/82609

私の答えを質問の範囲にとどめるために、ここに興味深い部分があります：

例外コードを避ける

例外タイプは、フロー制御の決定に十分なはずです。例外の解析やフロー制御は、役に立たないコードを作成するだけです。例外コードがある限り、例外タイプを追加します。

項目 39: 例外は例外的な条件にのみ使用する (Jochua Bloch の「Effective Java」の章) :

項目 39: 例外は、例外的な状況に対してのみ使用します。つまり、最初に Iterator.hasNext() をチェックする代わりに、Iterator.next() を呼び出すときに NoSuchElementException をキャッチするなど、制御フローに例外を使用しないでください。

関数型言語では、本当に例外的な条件に対してのみ例外を使用する傾向があります。例外的な条件は、「データベースに接続できない」などであり、「ユーザーが入力テキストで希望する商品の数量を提供しなかった」などではありません。これは例外ではなく、業務上のエラーです。

Java 言語はそれほど役に立ちませんが、理想的には、AddProductToBasketWithoutQuantityException を作成する代わりに、関数の出力 (たとえば、EnumAddBasketError のインスタンス) としてそのビジネス エラーを返すことができます。実際には、人々は例外を発生させ、通常の制御フローを壊し、アプリケーションを遅くする傾向があります (例外にはコストがかかります)。

チェック例外を避ける

ここで私の他の回答を読んでください: https://stackoverflow.com/a/16172074/82609 チェックされた例外は、回復可能な障害用です (Sun の推奨事項)。非チェック例外は、回復不能な障害の処理がより簡単です。

結局のところ、これらすべての例外はおそらく必要ないということです。それらのほとんどはおそらく回復不能であるか、例外的ではない可能性があるからです。

于 2013-04-21T00:31:21.640 に答える