为什么在binDebug中运行exe时不抛出跨线程操作异常 [英] Why is cross thread operation exception not thrown while running exe in binDebug

问题描述

我正在调试一个应用程序，在代码的某处，一个线程试图访问由另一个线程创建的列表框.在尝试访问列表框时，应用程序在调试时抛出跨线程操作无效:控制 'listbox' 从线程访问，而不是在其创建的线程上访问"异常.但是，当我在 binDebug 文件夹中运行此应用程序的输出时，我没有收到异常对话框，并且可以看到从非所有者线程成功访问了列表框，因此这让我认为此处存在行为差异，不仅仅是一个被抑制的异常.我可以通过 form_load 事件中的以下行在调试中解决此异常

I was debugging an application and somewhere in the code, a thread tries to reach a listbox that was created by another thread. On attempt to access the listbox, the application throws a "Cross-thread operation not valid: Control 'listbox' accessed from a thread other than the thread it was created on" exception while debugging. However, when I run this application's output in binDebug folder, I do not get an exception dialog and I can see that the listbox is successfully accessed from the non-owner thread, so this makes me think that there is a behavioral difference here, not just a suppressed exception. I can get past this exception in debugging with the following line in form_load event

Control.CheckForIllegalCrossThreadCalls = false;

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

But what is the reason behind this different behavior?

推荐答案

是的，这仅在附加调试器时检查.这是必要的，因为有很多 .NET 1.x 代码违反了这条规则.这不是一个明显的.

Yes, this is only checked when a debugger is attached. This was necessary because there was lots of .NET 1.x code that violated this rule. It is not an obvious one.

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

The bigger problem is that such code got away with it. Either by luck, not thinking too much about the occasional painting problems or by thinking that aborting the app when it deadlocked and restarting it once a day was acceptable. Because the programmer had no real hope of discovering the problem without a diagnostic.

微软非常关心向后兼容，即使它是有缺陷的兼容.修复非常好，即使它有时是错误的(Show(owner) 在不应该被检查时被选中).有时会忽略检查框架中的代码何时违反了规则.当线程依赖是间接的时会发生这种情况.最常见的情况是更新工作线程中数据绑定控件的数据源(首先解除绑定！)并使用侦听 SystemEvents.UserPreferenceChanged 事件的控件(不要在第二个线程上创建 UI！)

Microsoft cares a lot about backward compat, even if it is buggy compat. The fix is excellent, even though it is sometimes wrong (Show(owner) is checked when it shouldn't). And sometimes overlooks to check when it is code in the framework that violates the rule. Which happens when the thread dependency is indirect. Most common cases of that are updating the data source of a data-bound control in a worker thread (unbind first!) and using a control that listens for the SystemEvents.UserPreferenceChanged event (don't create UI on a second thread!)

作为参考，Control类的静态构造函数中有相关代码:

For reference, the relevant code is present in the static constructor of the Control class:

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

这篇关于为什么在binDebug中运行exe时不抛出跨线程操作异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！