为什么在bin \ Debug中运行exe时不会抛出跨线程操作异常

Question

我正在调试应用程序并在代码中的某个地方，一个线程试图到达由另一个线程创建的列表框。在尝试访问列表框时，应用程序抛出“跨线程操作无效：控制'列表框'从其创建的线程以外的线程访问”调试时出现异常。但是，当我在bin \ Debug文件夹中运行此应用程序的输出时，我没有得到异常对话框，我可以看到从非所有者线程成功访问列表框，所以这让我觉得这里存在行为差异，而不仅仅是一个被抑制的异常我可以通过form_load事件

中的以下行调试此异常

Control.CheckForIllegalCrossThreadCalls = false;

但这种不同行为背后的原因是什么？

Answer 1

是的，仅在连接调试器时检查。这是必要的，因为.NET 1.x代码的 lot 违反了这条规则。这不是一个明显的问题。

更大的问题是这样的代码侥幸逃脱了。要么运气好，不要过多考虑偶尔出现的绘画问题，要么认为在应用程序陷入僵局并且每天重新启动一次是可以接受的时候中止应用程序。因为程序员没有真正希望在没有诊断的情况下发现问题。

微软非常关注向后竞争，即使它是错误的竞争对手。修复非常好，即使它有时是错误的（显示（所有者）时应该检查它）。有时会忽略检查框架中违反规则的代码。当线程依赖是间接的时会发生这种情况。最常见的情况是更新工作线程中的数据绑定控件的数据源（首先取消绑定！）并使用侦听SystemEvents.UserPreferenceChanged事件的控件（不要在第二个线程上创建UI！）< / p>

---

作为参考，相关代码存在于Control类的静态构造函数中：

static Control()
{
    //...
    checkForIllegalCrossThreadCalls = Debugger.IsAttached;
    //...
}