C＃でエンタープライズプロジェクトのエラーコードパターンを作成するためのベストプラクティス[非公開]

私は多くのSMBや企業に展開されるエンタープライズプロジェクトに取り組んでいます。
このプロジェクトのサポートは苦労するため、エラーのコーディングパターン（HTTPステータスコードなど）を作成したいと思います。これにより、ヘルプデスクの担当者がドキュメントを参照し、できるだけ早く問題をトラブルシューティングできます。

これを行うためのベストプラクティスと推奨事項は何ですか？
これを行うためのヘルプは役に立ちます。

エラーコードとエラー戻り値には違いがあります。エラーコードは、ユーザーとヘルプデスク用です。エラー戻り値は、コードでエラーが発生したことを示すコーディング手法です。

エラー戻り値を使用してエラーコードを実装することもできますが、それに対してアドバイスします。例外はエラーを報告する最新の方法であり、エラーコードを例外に含めない理由はありません。

これは私がどのように整理するかです（ポイント2-6は言語に依存しないことに注意してください）：

1. 追加のErrorCodeプロパティを持つカスタム例外タイプを使用します。メインループのキャッチは、通常の方法でこのフィールドを報告します（ログファイル/エラーポップアップ/エラー応答）。すべてのコードで同じ例外タイプを使用します。
2. 1から始めたり、先行ゼロを使用したりしないでください。すべてのエラーコードを同じ長さに保つので、間違ったエラーコードを見つけやすくなります。通常、1000から開始するだけで十分です。主要な「E」を追加して、ユーザーが明確に識別できるようにします（特に、サポートデスクがユーザーにエラーコードを見つける方法を指示する必要がある場合に役立ちます）。
3. すべてのエラーコードのリストを保持しますが、コードではこれを行わないでください。開発者向けのWikiページに短いリストを用意しておき、新しいコードが必要なときに簡単に編集できるようにします。ヘルプデスクには、独自のウィキに個別のリストが必要です。
4. エラーコードに構造を強制しようとしないでください。分類するのが難しいエラーは常に存在するため、エラーが45xxグループと54xxグループのどちらにあるべきかを何時間も議論したくはありません。実用的である。
5. コード内の各スローに個別のコードを割り当てます。同じ原因だと思っていても、ヘルプデスクはさまざまなケースでさまざまなことをする必要があります。Wikiに「E1234：See E1235」を含める方が、ユーザーに間違ったことを告白させるよりも簡単です。
6. ヘルプデスクが要求した場合、エラーコードを分割します。if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");コード内の簡単な行により、ヘルプデスクの時間を30分節約できます。

そして、エラーコードの目的がヘルプデスクの生活を楽にすることであることを決して忘れないでください。

最初に、エラーが発生する可能性があり、ユーザーに見える領域を分離する必要があります。その後、それらを文書化できます。そのシンプル。

理論的には単純です。実際には、エラーはすべての場所で発生する可能性があり、エラーを報告することで、素晴らしいコードをロギング、例外のスローと処理、戻り値の受け渡しのモンスターに変えることができます。

その場合、2段階のアプローチをお勧めします。まず、ログを記録し、ロットとロットを記録します。

2つ目は、主要なコンポーネントとそのインターフェイスを決定し、これらのコンポーネントが検出できる主要なエラーケースを定義することです。これらのエラーの1つ（エラーの内部処理方法はユーザー次第）で、よりわかりやすい方法でログインできます-例外またはエラーコードはここでは違いはありません）。ユーザーは通常、エラーを確認し、ログを参照して詳細情報を確認します。

同じアプローチがWebサーバーとhttpエラーコードの例に使用されます。ユーザーが404を確認し、サポートに報告すると、ログで何が起こっているのか、どのページにアクセスしたのか、いつ閲覧したのかなど、詳細な情報を収集します、DB、ネットワーク、またはアプリケーション内にあります。

説明的な名前と明確なメッセージを含むカスタム例外に行き、それらをスローします。エラーコードを渡したり解釈したりするためのサポートを組み込むよりも、言語の既存の例外インフラストラクチャを使用する方がはるかに簡単です。