Exceptionロギングプログラムに取り組んでいますが、ネストされた呼び出し構造を介して浸透しているため、繰り返しロギングされているときに同じオブジェクトを繰り返し処理することは避けたいと思います。そのため、Exceptionオブジェクトを1回フォーマットし、フォーマットされたバージョンに一意の「例外番号」を付けてから、Exceptionオブジェクトに何らかのタグを付けて、後のログ呼び出しで再び検出された場合に認識できるようにしたいと思います。
私が思いついたアイデアは、オブジェクトのHelpLinkフィールドを誤用することです。Exception「例外番号」の文字列バージョンを含むように設定します。次にException、別のログ呼び出しでオブジェクトが一時的に再び表示された場合、そのオブジェクトを認識できます。
しかし、これはおそらく悪い考えですか？思いもよらなかった落とし穴はありますか？もしそうなら、誰かがより良いアイデアを持っていますか？
編集：状況をもう少し説明するために、このロガーは私自身のプログラムでのみ使用されます。
'abusing'HelpLinkプロパティ の代わりに、Dataプロパティを使用してに追加情報を追加できますException。これには、例外に関する追加のユーザー定義情報を提供するキーと値のペアが含まれています。
私はTheVillageIdiotに同意しますが、より一般的に言えば、Exceptionの動作を変更する場合は、追加の関連情報を追加する独自のExceptionクラスを作成する必要があることを指摘します。結局のところ、継承とポリモーフィズムを使用するのはそのためです。:)
Exception.HelpLinkロガーは、特定の形式またはデフォルトの形式でのみ例外情報をログに記録する必要があるため、使用するのは間違いなく問題ありません。同じ例外が何度も発生する場合は、ロガーではなく、実行中のアセンブリまたはプログラムの問題です。
さらに良いことにlog4net、log4.netによって作成/更新されたログファイルまたはデータベーステーブルから例外をフォーマット/グループ化するためのログおよびカスタムレポートインターフェイスに使用するオプションを調べることができます。
コードは、すべてのレベルで例外をキャッチしてログに記録するべきではありません。コードで同じ例外が2回発生する理由はありません。これは、主要なアンチパターンである「すべての例外をキャッチ」を使用しているように聞こえます。
いいえ、HelpLinkを誤用することは許されません。@Greeboが述べたように、追加のプロパティが必要な場合は、独自の例外クラスを作成できます。別の方法として、クラスDataの一部であるプロパティを使用することもできます。System.Exception
質問：例外ハンドラーはロギング以外の処理を行っていますか？
そうでない場合は、ハンドラーは必要ない可能性があります。例外（クリーンアップにfinallyブロックを使用）を呼び出しスタックにバブルさせ、最外層で処理します。ハンドラーが例外を処理している場合、スタックのさらに上で同じ例外が発生する理由がわかりません。内部例外を処理されたものに設定する新しい例外を作成する可能性が高いと思います。