これはログに記録されているものです:
ex.ToString()
おそらく、ログに記録しているのはそれだけだからです。このようなものは、ロギングステートメントですか?:
catch (Exception ex)
{
Logger.Log(ex.ToString());
}
ログに記録されているものにさらに情報を追加する方法は、それをロガーに渡すことです。このようなもの:
catch (Exception ex)
{
Logger.Log(string.Format("Failed to get a Name for the ID: {0} - Exception was: {1}", ID, ex.ToString()));
}
これは、文字列のみをログに記録していると想定しています。おそらくこれを拡張して、ロガー自体に直接渡されるカスタム例外を使用して、より厳密に型指定されたデータを含めることができます。ロガーの機能について詳しく知らなければ、なんとも言えません。おそらく、パラメーターをその文字列表現に内部的に追加するジェネリック型パラメーターを使用したカスタム例外でしょうか? 繰り返しますが、この 1 つの単純な例については、詳細な情報がなければ何とも言えません。
全体を汎用にすることに関しては、それは実際には独自の設計次第です。提供する 2 つのメソッド シグネチャには、パラメータが 1 つしかありません。そのため、カスタム例外の単一のジェネリック プロパティが機能します。複数のパラメータを持つメソッドはどうですか? 独自のパラメーターを超えたコンテキストを持つメソッドはどうですか? (たとえば、メソッドのクラスのインスタンス プロパティ)。
それぞれの例外は潜在的に大きく異なります。各コード ブロックは、ドメイン内の独自のロジックです。そして、意味のあるコンテキストをエラーとともに提供すること (ちなみに、これは優れた方法です) は、多くの場合、それらのコード ブロックのロジックの違いに対して非常に主観的です。強く型付けされた情報である場合もあれば、状況に関する人間が判読できるコンテキストである場合もあります。
レガシ コードを使用する場合、実行可能な長期的なアプローチは、追加情報が必要なエラーを特定し、エラー処理コードを変更してその情報を提供することです。多くの場合、本番環境への 1 回のパスで多くを捕まえることができますが、ストラグラーも存在します。やがてその数は減少するでしょう。多くの場合、1 つのエラーを修正するために 2 つの製品リリースが必要になるため、これは管理者の観点から最も望ましいアプローチではありません (1 つのリリースではログを追加し、別のリリースでは必要なランタイム情報が提供された後に実際にエラーを修正します)。しかし、まあ、それは次のような悪いコードの新しい宝石から生じる技術的負債です。
catch (Exception ex)
{
Logger.Log(ex.ToString());
}