2012-04-11 7 views
0

プロジェクトからプロジェクトにコピーされる定型コードの量を減らすために構築したDLLライブラリがあります。 dllにはRPCを介してマシンとの接続を維持するためのタイマーがあります。私のプロジェクトをデバッグし、RPC接続を中断すると、私のコードは正常にdllライブラリから切断イベントを受け取り、私のメインフォームはイベントをキャッチし、それを適切に処理します。DLLから未処理の例外がリリースビルドにのみ表示される

リリースのためにビルドします。私がRPC接続を壊すと、他の場所では見逃せないライブラリから未処理の例外が投げられます。

例外をスローしているコードがタイマーにあり、呼び出しがtry/catchブロックですべてラップされ、catchブロックが例外を呑み込んで他のクリーンアップ作業を行うということです。

デバッグモードではすべてがうまくいくわけではありませんが、リリースではそれはできません。その部分は私には意味をなさない。私は例外オブジェクトを見て、それに処理されたプロパティを設定しようとしましたが、利用できません。私が見ているこの正常な行動ですか?

私は最近、自分のプロジェクトで、数多くのライブラリを活用して、自分のソリューションをより整理して従いやすいように保ち始めました。うまくいけば、これは私が考慮しなかったライブラリの問題ではない。

+0

問題を絞り込む必要があります。例外がスローされている場所を調べるために、いくつかのログ関数を追加してみてください。 – squelos

答えて

2

Try-Catch in Releaseモードで捕捉されないいくつかのタイプの例外があります(たとえば、別のスレッドで発生しているものなど)。メインフォームでApplication.ThreadExceptionイベントを処理してみてください。

Application.CurrentDomain.UnhandledExceptionを処理して、未処理の例外がすべてキャッチされていることを確認することもできます。

+0

上記のリンクの例のように、Application.CurrentDomain.UnhandledExceptionイベントにもアタッチしてください。 – davisoa

+0

私は通常これらのイベントには添付しません。私はそれを撃つだろう。これがスレッドに関連する例外の場合、デバッガはスレッドコンテキストを制御するため、コードをステップ実行しても表示されません。 – TWood

+0

よく私はthreadexceptionのハンドラを追加しましたが、私の問題はまだそれによって捕らえられず、未処理の例外ハンドラが正常にアプリケーションをシャットダウンしました。問題を解決するために、私はクラスを私のdllから移動してメインプロジェクトに戻さなければなりませんでした。その後、エラーが発生するたびにそのエラーをキャッチできました。 – TWood

関連する問題