9

アーキテクチャの観点から例外をどのように使用するかを計画するための適切なリソースはありますか? (または、ここで直接提案を提供してください。) 私が取り組んだプロジェクトでは、いくつかの一般的な例外が何度も何度も使用され、意味を失う傾向があることがわかりました。から: http://jamesjava.blogspot.com/2007/10/exception-plan.html

4

4 に答える 4

2

私は Apocalisp のコメントに半分同意します。例外のインスタンスは、データ エラーまたは処理エラーが発生した場合のために予約する必要がありますが、ユーザーまたはシステムの介入によって回復できます。アプリケーションの範囲内で介入しても問題を解決できない場合のために、RuntimeException のインスタンスを予約する必要があります。したがって、これら 2 つのタイプは、Checked 例外と Unchecked 例外として知られています。

Unchecked 例外の例としては、物理リソース (データベースやメッセージ バスなど) が利用できない場合があります。この場合、RuntimeException は適切です。なぜなら、リソースが使用不可になることを計画していないためです。そのため、ビジネス ロジックは DatabaseUnavailableException などを常にチェックする必要はありません。停止を報告し、スタッフまたはサポートに物理的な問題を修正させるために、RuntimeExceptions を別の方法 (おそらく AOP が電子メールを送信する) で処理することができます。

チェックされた例外の例としては、不十分なデータ入力、不完全なデータ アクセス、または実際にはビジネス ロジックに失敗しているが、チェックして回復できるものなどがあります。この例として、検索したユーザーが利用できない場合があります。これは、チェックして処理できるビジネス ロジック内の別の条件です (たとえば、アプリケーションのビュー部分によって、例外のメッセージがエラー メッセージとしてユーザーに報告されます)。

多くのフレームワークがこのモデルを使用しており、他の方法で見たよりもうまく機能しているようです。

そうは言っても、多くの場合、チェックされた例外を返された null、-1、空の文字列、または Number.MIN_VALUE に置き換えます。これは問題ありませんが、データソースまたはメソッドからこれらの値を定期的に期待していない場合は、おそらく例外として表示する必要があります。

于 2008-09-23T20:15:08.707 に答える
2

私は一般的に、チェックされた例外に執着するのはやり過ぎだと思います。例外は、プログラムが合理的に回復できない予期しないエラー状態のために予約する必要があります。これらについては、特別なエラーの種類は意味を失う傾向があるというあなたの観察に同意する傾向があります。

原則として、次のすべてに該当する場合に例外をスローします。

  • ここから状態を回復することはできません。
  • 呼び出し元がこの状態から回復することは合理的に期待できません。
  • 誰かが状況をデバッグしたいので、スタック トレースを見たいと思うかもしれません。

これらすべてが当てはまる場合、例外のタイプは重要ではなく、java.lang.Error をスローすることもできます。それらのいずれかが false の場合、例外はおそらくやり過ぎです (型、メッセージ、およびスタック トレースが本当に必要ですか?)

代わりに、メソッドの戻り値の型を増やして、予想される種類の失敗を示すことを検討してください。たとえば、場合によっては値を返さないことが理にかなっているメソッドにはOption<A>型を使用します。タイプが失敗または成功に依存する値を返す必要がある可能性があるメソッドには、Either<A,B>タイプを使用します。以前に特別な Exception サブタイプを使用していた可能性がある場合は、代わりに、Either<Fail,A> を使用できます。ここで、Fail は、予想される種類のエラーの単なる列挙です。

于 2008-09-17T21:21:01.370 に答える
0

私は、try/finally を使用する場所の数が、try/catch を使用する場所の数よりもはるかに多いことを確認しようとしています。通常、catch はトップレベルで例外をキャッチするために予約されます。例外は適切に処理されるか、プラットフォーム API からの例外を処理します。

この場合、例外に意味のあるメッセージを与え、必要に応じて例外をチェーンする限り、クラスで例外を識別できなくても大きな損失にはなりません。考えられるすべてのエラーケースに対して例外クラスを開発しようとするのではなく、RuntimeException をスローすることがよくありますが、それに関するあなたの意見は、チェックされた例外とチェックされていない例外の議論のどこに座っているかによって異なります。

于 2008-09-17T20:45:34.887 に答える
0

「実効Java」第2弾。編。Blochは、第 9 章でいくつかの良いアドバイスをしています。

「Hardcore Java」の Simmonsは、第 5 章でいくつかの適切なアドバイスを提供しています。

また、 Java 例外のソース コードを管理するための小さなツールを作成したことも恥知らずに述べておきます。例外コードは非常に冗長であることが多く、通常気にするのは型だけです。私のツールは、例外の種類を指定する構成ファイルを受け入れ、それらの例外のコードを生成します。

于 2008-09-17T20:37:40.583 に答える