10

デバッグ中とコンパイル済みの.exeを実行しているときでは、例外がキャッチされるかキャッチされないという異なる動作が見られます。2つのフォーム（Form1とForm2）があります。Form1には、Form2でShowDialogをインスタンス化して呼び出すボタンがあります。Form2には、意図的にゼロ除算エラーを生成するボタンがあります。デバッグしているときに、Form1のcatchブロックがヒットします。コンパイルされた.exeを実行してもヒットせず、代わりに「アプリケーションで未処理の例外が発生しました。[続行]をクリックすると、アプリケーションはこのエラーを無視して続行を試みます。 [終了]をクリックすると、アプリケーションはすぐに閉じます...ゼロ除算を試みました。」私の質問は、デバッグ時と.exeの実行時に異なる動作が発生するのはなぜですか？それが予想される動作である場合、次に、すべての単一のイベントハンドラーにtry / catchブロックを配置する必要があると見なされますか？それは殺すのにちょっとクレイジーに思えますね？

Form1のコードは次のとおりです。 

public partial class Form1 : Form
{
    public Form1()
    {
            InitializeComponent();

    }

    private void button1_Click(object sender, EventArgs e)
    {
        try
        {
            Form2 f2 = new Form2();
            f2.ShowDialog();
        }
        catch(Exception eX)
        {
            MessageBox.Show( eX.ToString()); //This line hit when debugging only
        }
    }
}

Form2のコードは次のとおりです。

public partial class Form2 : Form
{
    public Form2()
    {
            InitializeComponent();
    }

    private void button1_Click(object sender, EventArgs e)
    {
            int x = 0;
            int y = 7 / x;

    }
}
4

2 に答える 2

11

はい、これは仕様によるものであり、Windowsフォームの動作と密接に関連しています。Winformsアプリでは、Windowsによってアクティブなウィンドウに投稿されたメッセージに応答してコードが実行されます。すべてのネイティブWindowsアプリには、これらのメッセージを検出するためのメッセージループが含まれています。Winforms配管は、イベントハンドラーの1つが応答して実行されることを保証します。button1_サンプルコードをクリックします。

ほとんどのWinformsコントロールは、独自のイベントハンドラーを実装しています。たとえば、PictureBoxには、画像が画面に描画されるようにするPaintイベントハンドラがあります。これはすべて自動的に行われ、これを機能させるために自分でコードを書く必要はありません。

ただし、このコードが例外をスローする場合は問題があります。独自のコードが含まれていないため、このような例外をキャッチする方法はありません。つまり、独自のtryブロックを挿入する場所はありません。関与した独自のプログラムのコードの最後のビットは、メッセージループを開始したコードです。Application.Run（）メソッドの呼び出し。通常はProgram.csにあります。または、ダイアログを表示する場合はForm.ShowDialog（）を呼び出します。これらのメソッドのいずれかがメッセージループを開始します。Application.Run（）呼び出しの周りにtryブロックを配置することは役に立ちません。アプリは、例外をキャッチした後に終了します。

この問題に対処するために、Winformsメッセージループコードには、イベントをディスパッチするコードの周りにtryブロックが含まれています。そのcatch句は、あなたが言及したダイアログを表示します。これは、ThreadExceptionDialogクラスによって実装されます。

質問のポイントに到達する：このcatch句は、デバッグ時にコードの問題をトラブルシューティングする際に実際に邪魔になります。デバッガーは、例外を処理するcatchブロックがない場合にのみ、例外で停止します。ただし、コードが例外をスローした場合は、デバッグ時にその例外について知りたいと思うでしょう。メッセージループ内の前述のコードは、デバッガーが接続されているかどうかを認識しています。そうである場合は、try/catchブロックなしでイベントをディスパッチします。これで、コードが例外をスローすると、それを処理するcatch句がなくなり、デバッガーがプログラムを停止して、何が悪かったのかを見つける機会が与えられます。

おそらく、プログラムがそのように動作する理由がわかります。デバッグすると、メッセージループのcatch句が無効になり、Form1コードのcatch句が例外をキャッチする機会が与えられます。そうしないと、メッセージループのcatch句が（ダイアログを表示することによって）例外を処理し、例外がForm1コードに巻き戻されるのを防ぎます。

UnhandledExceptionMode.ThrowExceptionを渡してApplication.SetUnhandledExceptionMode（）メソッドを呼び出すことにより、メッセージループのcatch句がまったく使用されないようにすることができます。Application.Run（）を呼び出す前に、Main（）メソッドでこれを行います。これで、プログラムはどちらの方法でも同じように動作します。

これは一般的に悪い考えではありません。例外ダイアログで続行するオプションをユーザーに提供することは疑わしい機能です。その場合は、AppDomain.UnhandledExceptionイベントのイベントハンドラーを実装して、ユーザーに少なくともある程度の診断が行われるようにしてください。

于 2009-11-21T17:39:46.000 に答える
4

私はあなたと同じ振る舞いをします。なぜこれが発生するのかはわかりませんが、フォーム内のイベントから生成された例外がShowDialog（）呼び出しのスタックに表示されると想定するのは悪い考えのようです。次の2つのことを行う方がよいでしょう。

  • Form2のイベントハンドラーで例外をキャッチして処理します。これは、そうすることが理にかなっている場合と、例外で意味のあることを実行できる場合です。
  • アプリケーション全体に未処理の例外ハンドラー（ `Application_ThreadException`）を追加して、未処理の例外をキャッチします。

更新：これがスタックトレースです。デバッグバージョン：

System.DivideByZeroException: Attempted to divide by zero.
   at WindowsFormsApplication1.Form2.button1_Click(Object sender, EventArgs e) in ...\WindowsFormsApplication1\Form2.cs:line 27
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.RunDialog(Form form)
   at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
   at System.Windows.Forms.Form.ShowDialog()
   at WindowsFormsApplication1.Form1.button1_Click(Object sender, EventArgs e) in ...\WindowsFormsApplication1\Form1.cs:line 45

リリース：

System.DivideByZeroException: Attempted to divide by zero.
   at WindowsFormsApplication1.Form2.button1_Click(Object sender, EventArgs e) in ...\WindowsFormsApplication1\Form2.cs:line 27
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

System.Windows.Forms.Form.ShowDialog()リリースモードではスタックトレースにないことに注意してください。これが、try {} catch {}何もしない理由です。NativeWindow.DebuggableCallbackまた、デバッグの場合は、スタックを壊さないことでデバッグを支援するように設計されていると思われるを使用しているのに対し、リリースモードではを使用していることも注目に値しますNativeWindow.Callback。

于 2009-11-21T16:20:47.923 に答える