.net - カスタム例外タイプは「自己ログ」です - それは悪いことですか?

Question

私は、チームがカスタム例外タイプを定義したプロジェクトに参加しています。そのコンストラクターには、コンストラクターに渡された例外をログに記録する Logging メソッドへの呼び出しがあります。

私はこれが悪いと思ったでしょう - そうですか？

問題は、「自己ログ」を削除することはできますが、そこにあるログにどれだけの人が依存しているかがわからないことです。

Answer 1

C++ コミュニティは、構築中に例外を処理する適切な方法について永遠に議論しました。問題は、コンストラクターで何かをスローしている場合、オブジェクトを構築できなかったことを意味するはずです。代わりに、コードが物事が最適ではないことを指摘しているだけであるが、構築は続行されている場合は、他の方法で行う必要があります。これにより、制御フローの例外を使用しないアンチパターンが呼び出されます。

Answer 2

と言うか、多分ダメです。同僚が少し前に書いたコードを読んだことを思い出します - パブリックヘルパーメソッドで、例外をスローする代わりに、エラーメッセージで MessageBox.Show() を実行しました。これはいくつかの理由でかなり悪いことでした。そのうちの 1 つは、ユーザーにばかげたエラーを表示せずにメソッドを使用したかったことです。

個人的には、メソッドが情報をログに記録するかどうか (ほとんどの場合) を制御できるようにしたいと考えています。ログ ファイルが乱雑にならないように例外を処理したい場合はどうすればよいですか?

一方で、おそらくコードを書いた人は、他のプログラマーがログに記録すべきときにログを記録しないことを避けるために、意図的にこのように設計したのでしょう。シナリオによります。

これは懸念事項の分離の問題であるため、個人的には好きではありません。ロギングは、メソッドが実行しようとしているタスクから切り離されているはずです。ロギングがそのタスクの重要な部分でない限り。また、特定の例外については、ロギングが非常に重要になる場合があります。

Answer 3

悪いと思います。未処理の例外イベント ハンドラを使用してそれらをすべてキャッチし、そこで適切なログを記録してみませんか? あなたがそれを説明する方法は、Single Responsibility Principle (SRP) に違反しています。また、例外がシリアル化可能であることも覚えておいてください。たとえば、サービス コンテキスト (WCF サービスなど) で例外を生成し、それをクライアント (Web /desktop アプリケーション) ロギングはどこで行われますか? このような質問/問題は、ロギングを例外から分離し、それらを分離しておくことが最善であることを教えてくれます。