sFTP (ssh.net) を使用したファイル転送に c# で Windows サービスを使用しています。コードのすべてのブロックで例外を処理しましたが、未処理の例外が発生し、Windows サービスがクラッシュします。
を使用して未処理の例外について理解しました
AppDomain.CurrentDomain.UnhandledException
この未処理の例外を回避し、サービスがクラッシュするのを回避することは可能です。
前もって感謝します。ビジェイ
sFTP (ssh.net) を使用したファイル転送に c# で Windows サービスを使用しています。コードのすべてのブロックで例外を処理しましたが、未処理の例外が発生し、Windows サービスがクラッシュします。
を使用して未処理の例外について理解しました
AppDomain.CurrentDomain.UnhandledException
この未処理の例外を回避し、サービスがクラッシュするのを回避することは可能です。
前もって感謝します。ビジェイ
いいえ、UnhandledException
プロセスがダウンしているという事実を変更しないためです。それが起こる前に何かをする機会を与えるだけです(例えば、失敗をログに記録する)。
そのように機能したとしても、実際にはサービスにバグがあります。それらを修正するためにもっと見るべきであり、それらを隠すためにもっと見るべきではありません。
この未処理の例外を回避し、サービスがクラッシュするのを回避することは可能です。
はい、そうです。それはまた、悪い設計上の決定でもあります。
AppDomain.CurrentDomain.UnhandledException
これは、クラッシュ レポートを作成してからサービスを再起動する最後の手段のハンドラーを配置するのに適した場所です。
例外を飲み込むのは賢明ではありません。予想されるすべての例外を処理する必要があります。
コードのすべてのブロックで例外を処理しましたが、未処理の例外が発生しています
自分が何をしているのかわからないように聞こえます。すべてのコード ブロックで例外を処理する必要はありません。例外ハンドラーでコードが完全にオーバーロードされます。ただし、意味のある適切な例外処理を行い、すべての SENSIBLE (予想される) 例外をキャッチする必要があります。
サービスのクラッシュを回避することは賢明ではありません。なぜなら、どのような例外があるのか わからない場合、サービスがクラッシュするのではなく、サービスが破損する可能性があるためです。信頼できるサーバー システムを作成する唯一の方法は、フェイル ファスト アンド ハードです。
未処理の例外を回避する唯一の方法は、未処理の例外を持たないことです! サービスが別のスレッドで例外をスローする可能性のあるマルチスレッド機能を利用していないと仮定すると、ServiceBase.Run 呼び出しの周りに例外ハンドラーを配置することで回避できます。
このようにして、すり抜けた例外を最後の最後でキャッチして処理することができます。通常は、これらの下部をつかみ、それに応じて処理したいと考えていますが、
スレッド化されたアプリケーションでは、生成された新しいスレッドがメインスレッドでスローされず、この「キャッチオール」ハンドラーによって処理されないため、少し難しくなります。
編集:
これを行うことを容認しないことを付け加えるかもしれません-理想的には、適切な場所で例外を処理する必要があります-予期しない未処理の例外が発生した場合は、スタックを調べて何が問題なのかを確認する必要があります。AppDomain.UnhandledException にハンドラーを追加し、例外ツリーとスタックをログに書き込むと役立ちます (何らかのログ メカニズムがありますよね?)。それかデバッグか