后台工作者事件处理答案

【问题标题】：Background Worker Event Handling后台工作者事件处理
【发布时间】：2009-03-20 00:18:30
【问题描述】：

我一直在努力处理后台工作线程中的事件。

我遇到的所有文档都让我相信，当 DoWork 事件处理程序引发异常时，应该在 RunWorkerCompleted 处理程序中处理该异常，并且该异常将在 RunWorkerCompletedEventArgs 的 Error 属性中可用。

这很好，但在调试期间，我总是看到用户代码消息未处理的异常。这让我相信我的方法有问题。

我应该采取什么步骤来解决这个问题？

问候，乔纳森

【问题讨论】：

标签： c# multithreading debugging backgroundworker

【解决方案1】：

我以前见过这种行为，我通过使用 System.Diagnostics.DebuggerNonUserCode 属性装饰 DoWork 处理程序来解决它：

[System.Diagnostics.DebuggerNonUserCode]
void bw_DoWork(object sender, DoWorkEventArgs e)
{ ... }

请注意，只有在调试器中运行时才能看到此信息；即使没有该属性，从 shell 运行时也应该如此。

我再次查找了此内容，但我仍然看不出您需要这样做的任何充分理由。我称之为调试器错误功能。

【讨论】：

为什么需要这样做？因为这是 BackgroundWorker 的工作方式。处理调用线程中的错误比处理工作线程中的错误要容易得多。但是在调试时，另一种方式是正确的，因为您可以访问所有局部变量。
我不认为“BackgroundWorker 就是这样工作的”是一个令人满意的答案。听起来您将所有异常都视为编码错误的指示-仅有时如此。如果我希望调试器在处理的异常上中断，我会打开第一次机会异常或设置断点。

【解决方案2】：

我以前遇到过这个问题。仅当您不在调试模式下运行时才会设置 e.Error。如果在 Debug 中运行，exectuion 会在异常处停止。但是，在非调试模式下运行相同的程序（在 VS Debug -> Start without Debugging 或 Ctrl+F5 中）并且讨厌的异常对话框不会出现，并且 e.Error 将是异常。不知道为什么，但这就是它的工作原理......

【讨论】：

【解决方案3】：

你的方法是正确的。只需在消息上按继续并继续。如果有疑问，请在调试会话之外对其进行测试。

【讨论】：