TargetInvocationException从BackgroundWorker_RunWorkerCompletedTargetInvocationException、BackgroundWor

2023-09-06 00:00:41 作者:不自量.

假设下面的情况。某个表单上点击启动一个后台工作人员的按钮。在RunWorkerCompleted事件处理程序中有一张code抛出unhandeled异常。该表格​​是从Application.Run方法开始。

Suppose the following situation. A form has a button that on click starts a background worker. In RunWorkerCompleted event handler there is a piece of code that throws unhandeled exception. The form is started from Application.Run method.

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

    private void backgroundWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
    {
        throw new Exception();
    }

    private void button_Click(object sender, EventArgs e)
    {
        backgroundWorker.RunWorkerAsync();
    }
}

问题是,Visual Studio中的断线Application.Run调用,而不是在抛出新的异常()中的FormMain.backgroundWorker_RunWorkerCompleted方法。在真正的例外的顶部是包裹着TargetInvocationException和调用堆栈会降低,导致因该异常不能检查Program.Main方法和code。

The problem is that Visual Studio breaks at Application.Run call instead at "throw new Exception()" in FormMain.backgroundWorker_RunWorkerCompleted method. On top of that real exception is wrapped with TargetInvocationException and call stack is reduced to Program.Main method and code that caused exception can't be inspected because of that.

如何prevent的包装?我做得本质上的错误?

How to prevent that wrapping? Am I doing something intrinsically wrong?

这与TargetInvocationException提供的调用堆栈来看,有循环和线程的不那么基本的了解,很多堆积起来的调用方法,太多的消息我的基本理解。

Judging from the call stack supplied with TargetInvocationException, there are a lot of invocation methods stacked up, too much for my basic understanding of message loops and not-so-basic understanding of threading.

编辑: 我知道有在TargetInvocationException InnerException属性和错误可以通过查看有被跟踪,但不是问题。现在的问题是,如何让Visal演播室包装与TargetInvocationException真正的例外,这样我就可以使用所有这些很好的调试功能,VS IDE提供前停下来。

I know there is InnerException property in TargetInvocationException and that the error can be traced by looking there but that is not the question. The question is how to make Visal Studio stop before wrapping real exception with TargetInvocationException so I can use all those nice debugging features that VS IDE provides.

推荐答案

是的,这是从魔法使RunWorkerCompleted事件的UI线程上运行一个不幸的副作用。还有就是你写的,使得它运行,以便调试器不能显示相关的任何东西,但最后的声明是在你的程序还在参与的是,Application.Run()调用开始消息循环没有code。

Yes, this is an unfortunate side effect from the magic that makes the RunWorkerCompleted event run on the UI thread. There is no code that you wrote that made it run so the debugger cannot show anything relevant but the last statement that is in your program that was still involved, the Application.Run() call that started the message loop.

您必须通过强制调试器时,抛出异常停止调试此。调试+例外,勾选抛出复选框CLR例外。还要注意的行为,当你运行这个没有一个调试器,你会得到命运之轮对话。修复了与Application.SetUnhandledExceptionMode()。

You have to debug this by forcing the debugger to stop when the exception is thrown. Debug + Exceptions, tick the Thrown checkbox for CLR exceptions. Also note the behavior when you run this without a debugger, you'll get the Wheel Of Fortune dialog. Fix that with Application.SetUnhandledExceptionMode().