2

C# アプリケーションがあります。必要に応じてフラグなどを付けて、デバッグモードでコンパイルできます。

ある時点の後、正しく機能しなくなります (大幅なスローダウン、部分的なハングなど)。

明らかに何かがうまくいかない。最初の試みとして、プログラムの実行中にどこかで発生したすべての例外 (キャッチされたものとキャッチされなかったもの) の完全なリストを見たいと思います。出来ますか？VSには、特定の例外で「ブレークポイント」を設定できるオプションがあることを知っています。しかし、私は「ブレークポイント」をしたくありません。代わりに、発生したすべての例外を「ログに記録」して、後で分析できるようにしたいと考えています。

4

3 に答える 3

3

どこで例外が発生する可能性があるかわからない場合は、アプリケーションでUnhandledExceptionを使用してみてください。

UnhandledException イベントは、メイン UI スレッドからスローされたキャッチされていない例外を処理します。ThreadException イベントは、非 UI スレッドからスローされたキャッチされていない例外を処理します。

static void Main(string[] args)
{      
    AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
    //... do something ...      
}

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
      System.Diagnostics.Trace.WriteLine((e.ExceptionObject as Exception).Message, "Unhandled UI Exception");
      // here you can log the exception ...
}

ロギングに MSDN の Trace クラスを使用しました。

System.Diagnostics.Trace

これには、Trace()メソッドをリッスンし、ログ ファイル/出力ウィンドウ/イベント ログに書き込むリスナーが含まれます。含まれているフレームワークのリスナーはDefaultTraceListener、TextWriterTraceListenerおよびEventLogTraceListener. レベル (警告、エラー、情報) とカテゴリを指定できます。

于 2012-10-16T16:30:06.193 に答える
3

率直に言って、これには例外を使用しないでください。必要なのは、コード内の重要なアクティビティを日時スタンプで記録するようにアプリケーションを「装備」することです。これにより、何か問題が発生した後、時系列ログを確認して、コードが失敗したもの (および場所) を確認できます。期待されていることを実行したり、必要以上に時間がかかったりします。Microsoft Logging Application Block 、またはlog4Netを確認してください

一般に、例外の適切な使用は、アプリケーション (またはモジュール、またはサブルーチン/関数) が提供するように設計された機能を正常に完了できない場合に限定する必要があります。例外もログに記録する必要がありますが、重大な障害以外を追跡するために例外を使用しないでください。コードが障害から回復できない場合、ほとんどの場合、アプリが停止するだけです。

実際、何か問題が発生して例外がスローされた場合 (最も些細な問題を除いて) のほとんどの場合、例外がスローされた時点で入手できる情報は、問題を診断するための最初のステップにすぎません。それより前のコード実行パスで何が起こったのかは、実際の問題がどこにあるかです...

于 2012-10-16T16:33:25.953 に答える
0

質問に答えるには、(少なくとも部分的には) 独自のデバッガーを作成してプロセスにアタッチし、未処理の例外と処理済みの例外をすべて記録する必要があります。おそらく、ここから始めたいと思うでしょう。また、デバッグ インターフェイスのMSDN ドキュメントもここにあります。

これにより、[デバッグ] -> [例外] に移動し、例外がスローされたときにブレークするボックスをオンにしたときに Visual Studio が行うこととまったく同じことができるようになります。唯一の違いは、実行を停止する代わりに、例外がスローされた場所に関する情報を記録できる必要があることです (そして、例外の種類と思います)。最初に気付くのは、これが非常に複雑であるということです。うまくいけば、mdbg サンプルは必要なものに十分に近く、わずかに微調整するだけで済みます。

また、これはおそらく、解決しようとしている根本的な問題を解決する最善の方法ではないことも断言します。プログラムに未処理の例外がある場合、それらを見つけるための追加のヘルプはおそらく必要ありません。コードが次のようなことをしない限り、それらは表面に出てくるはずです:

try
{
    . . . Some operation
}
catch(Exception){ } //Muddle on through - Very Bad!!!

問題が、適切に処理されていない例外が処理されていることである場合、上記のアプローチは、問題の内容を絞り込むのにあまり役立ちません。

于 2012-10-16T17:42:54.650 に答える