コード行に対するキャッチステートメントの割合が良い

Question

大規模なソフトウェアでソースコード行あたりのキャッチステートメント数はどれくらいですか？

たとえば、C＃で書かれたソフトウェアの1つでは、Visual Studioは「catch」という単語を含む約350行を表示し、clocは約160k SLOC、30kコメント行、15k空白行があると報告します。 160k/350は、catchステートメントごとに約467行のコードです。

しかし、私たちは標準的なC＃の書式設定を自分の行に入れているので、160kからどれくらいの行が単括弧であるか知っているので、160kはいくつかのファイルをツリーはアプリケーションにコンパイルされなくなりました。私は、「有用な」比率が400 LOCあたり1つのキャッチに近いと推測するかもしれません。

少なくとも私の驚きではないが、私たちは空のキャッチブロックでキャッチされていた半クリティカルな例外を見逃していたので、今ではコードベースに行き、少なくとも例外をデバッグコンソール一時的な措置として、または捕らえられた例外についてより具体的になるようにすることができる。もちろん、これはアプリケーション全体のキャッチ数を増やしますが、それは「許容」ゾーンに近いところに私たちを連れてきますか？私は467 LOCあたり1つのキャッチが良い、ちょうど大丈夫、または恐ろしいかどうか分かりません。

---

私はよく を認識しています。なぜなら、は空のキャッチブロックを使用しないことです。他の/以前のメンテナーは怠け者です。また、この製品の次期リリースはタイムクリティカルなので、現在は300個ものキャッチコピーをすべて修正し、ソフトウェアの適切な動作を確認する時間はありません（もちろん、それを簡単にするためのテスト：/）

試し釣りがどのくらいの頻度で表示されるべきかについて「嫌な気持ち」があるかどうかを探していました。文脈に敏感であると答えたカップルの回答がありますが、それは私が疑いの種だが確かではないものです。

Answer 1

一般的な数字を示すのは非常に難しく、実際にアプリケーションが何をしようとしているのか、回復可能な方法でうまく動作しない操作を実行する必要があるのか​​どうかに大きく依存します。

大切なのは、空のキャッチブロックが実際には本当に悪いアイデアだということです。これはcatchブロックごとのコード行よりもはるかに重要です。

Answer 2

実際にに行く場合を除き、例外をキャッチするべきではありません。を処理してください。ハンドラが例外を元に戻したり、別の方法で値を追加したりすることができない限り、にはを処理できる人に例外をバブルアップする必要があります。

Answer 3

このような測定基準は完全に無視されます。コードの行を数えることは、必ずしも有用な指標ではありません。

ここでの真の答えは、文脈に完全に依存します。 catch文の「正しい」数は、発生する可能性のある例外を処理するために必要なtry/catchブロックの量です。これは正しく処理されます。適切に処理できる例外が発生する可能性がある場合は、try/catchブロックが必要です。あなたがそれを扱うことができない（またはそれを扱いたくない）なら、それは上向きに伝播する - それを捕らえないでください。

キャッチブロックの量は、あなたが書いているコードのタイプに完全に依存します。たとえば、ネットワークコードを書く場合、（ネットワークは本質的に処理される必要のある問題を持つ可能性が高いので）より多くの例外処理を実行する可能性が高くなります。

Answer 4

私の経験則は、例外を記録するすべてのイベントハンドラに少なくとも1つのルールを設定することです。

他の方法に関しては、try-catch-freeにすることをお勧めします。そのことが言われているが、私は、厄介なエラーレポート（ "parameter = value"）に状態を追加してから、プライマリハンドラに単にスローするcatchブロックを追加したことが何度もあります。あなたのバグ修正がうまくいけば、この方法は多くのデッドコードにつながります。