.net - Windows サービスをデバッグし、db ログを追加して、悪い考えをキャッチしますか?

Question

デバッグしようとしている Windows サービスがあります。

Catch() 句にエラー ログを追加するのは悪い考えですか?

私のロギングはデータベースを使用してエラーを記録しています。

Answer 1

デバッグとロギングの両方について言及しているので、私は100％明確ではなく、あなたが何をしようとしているのかはわかりません。

全体的なロギングアプローチの一部である場合、catch句にログオンすることは一般的に良い考えです。

サービスをデバッグした後の場合は、2つのオプションがあります。サービスの外部から（外部刺激を介して）デバッグしようとしているコードを制御できる場合、またはコードが実行される前に時間があれば、単に開くことができます。 VSのソースコード。デバッグモードでコンパイルしている限り、VSをサービスプロセスにアタッチできます。

次に、ソースコードに設定されたブレークポイントにより、デバッグ中のコードにアクセスできるようになります。

ただし、それができない場合（たとえば、開始イベントをデバッグする必要がある場合）、System.Diagnostics.Debugger.Break（）をソースコードに追加して、実行時にこの行がヒットしたときにデバッガーを開始できます。 。

私は通常、そのようなステートメントをコンパイルシンボルで#if#endifエリアコントロールにラップします。

Answer 2

私が担当するサービスでは、初期化後に発生するエラー（コードがデータベースに接続できることを確認し、ログファイルにアクセスし、作業を開始した後）がログファイルに記録されます。起動時またはシャットダウン時に発生するエラーは、イベントログに送信されます。

Answer 3

一般に、例外のロギングは良い考えです。特にサービスをデバッグするときは、常に厄介な作業です。

唯一の問題は、ログ自体が例外を引き起こすことです。これは、イベント ログに記録しているときに発生しました (詳細については、この質問を参照してください)。これは、サービスの失敗の原因となった例外に関する情報が得られないことを意味します。

デバッグの目的で、他のログ記録に加えて、例外をローカル テキスト ファイルに記録すると便利だと思います。それが最も失敗する可能性が低いです。デバッグが完了したら、これらの追加のロギング コマンドを削除できます。(まあ、それを行うときに新しいエラーを導入しないように注意する必要があります...)

Answer 4

コードによって異なります。一部のサービスでは、データベースに情報をログに記録しますが（これがここでのポリシーであるため）、データベースへのログ記録が失敗した場合にイベントログにメッセージを追加するセカンダリログメカニズムがあります。自分自身に問いかけなければならないのは、「データベースに接続できない場合、エラーはどうなるのか」ということです。