7

Java での例外処理に関していくつか質問があります。私はそれについて少し読んで、いくつかの矛盾するガイドラインを得ました。

例外処理のベスト プラクティス

言及された記事を見てみましょう：

「クライアントコードが何もできない」場合、一般的にチェック例外の使用を避けるべきであると述べています。しかし、それは正確にはどういう意味ですか？GUI にエラー メッセージを表示することは、チェックされた例外を発生させる十分な理由ですか? しかし、GUI プログラマーは、潜在的なエラー情報を表示するために、RuntimeExceptions とその子孫をキャッチすることを覚えておく必要があります。

この記事で提示された 2 番目の見解は、いくつかのカスタム フィールド/メソッドを実装する場合を除き、独自の例外クラスを発明することを回避する必要があるというものです。私は一般的にこれに同意しません。今日の私の実践は正反対でした。新しいメソッドを追加せずに Exception を拡張するだけであっても、作成したクラスによって実現される目標を反映するために、独自の例外構造に例外をラップしました。スローされたときに上位層でそれらをより柔軟に処理するのに役立つと思います。また、これらのクラスを使用するプログラマーにとって、一般的により明確で理解しやすいと思います。

私は今日、いくつかのコードを「新しい方法」で実装し、記事で提示されているように、あちこちで RuntimeException をスローしてから、Sonarに分析させました。さらに混乱させるために、Sonar は私の RuntimeExceptions をメジャー エラーとしてマークし、「ルート タイプの例外をスローしないようにして、独自のタイプでラップしてください」のようなメッセージを表示しました。

かなり物議を醸しているように見えますが、どう思いますか?

また、今日の技術リーダーの 1 人から、「JVM にとって非常にコストのかかる操作であるため、例外をラップするだけでは良くない」と聞いたことがあります。私にとっては、どこでも SQLExceptions または IOExceptions をスローすることは、カプセル化を少し破るように見えます..

では、私がここで提示した質問に対するあなたの一般的な態度はどうですか?

  1. 独自の型で例外をラップするのはいつですか?これを行うべきではないのはいつですか?

  2. 「クライアントはこれについて何もできない、実行時例外をスローする」というポイントはどこにありますか? '

  3. パフォーマンスの問題はどうですか？

4

1 に答える 1

2

あなたの技術リーダーは、開発者としての役割が苦手だったために、開発者としての役割を逃れたことがよくあるようです。

私のアドバイスは次のとおりです。

  • API の唯一のクライアントではない場合は特に、チェック済み例外よりも実行時例外を優先してください。チェックされた例外を使用すると、例外について何もできない場合でも、すべてのクライアントが例外を処理するように強制されます。これが本当にやりたいことである場合 (つまり、呼び出し元に強制的に処理させたい場合) は、チェック済み例外が必要です。
  • 例外が発生したときにクライアントができる唯一のことは、「おっと、何か問題が発生しました。再試行するか、ウェルカム ページに戻ってください」などの多かれ少なかれ一般的なエラー メッセージを表示することである場合は、必ず実行時例外を使用してください。プレゼンテーション フレームワークのほとんどは、一般的なエラー ハンドラーを使用する方法を提供します。
  • 抽象化レイヤーにリンクされている例外を必ず使用してください。高レベルのサービスから SQLException をスローするのは適切ではありません。適切な場合は、既存の例外タイプを使用します (IllegalArgumentException を使用して不正な引数を通知するなど)。それ以外の場合は、低レベルの例外を高レベルの適切な例外タイプにラップします。コストがかかるのは、例外をスローすることです。別のものをラップするかどうかはあまり重要ではありません。とにかく、それは例外的にのみ発生するはずです。
于 2012-10-16T21:15:49.787 に答える