为什么而BIN \\调试运行的exe不抛出跨线程操作异常 [英] Why is cross thread operation exception not thrown while running exe in bin\Debug

问题描述

我在调试应用程序中的某处code，A线程试图达到由另一个线程创建一个列表框。在尝试访问列表框，应用程序将引发跨线程操作无效：控制'的列表框的距离比它创建的线程以外的线程访问异常而调试。然而，当我运行此应用程序在BIN \\ Debug文件夹中的输出，我没有得到一个异常对话框，我可以看到列表框被成功地从非所有者线程访问，所以这让我觉得这里有一个行为差异，而不仅仅是一个SUP pressed例外。我可以突破这个例外调​​试与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 bin\Debug 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的code违反此规则是的地段的这是必要的。它不是一个明显的例子。

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.

更大的问题是，这样的code逃脱它。无论是靠运气，没有考虑太多，偶尔画的问题，或认为终止应用程序时，它陷入僵局并重新启动它每天一次是可以接受的。因为程序员有没有诊断发现问题没有真正的希望。

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.

微软非常关心向后compat的，即使是越野车COMPAT。解决方法是优秀的，即使它是错的，有时（显示（所有者）时，它不应该被选中）。有时可俯瞰检查时，它是违反规则的框架code。当线程依赖关系是间接的恰好。那最常见的情况下，正在更新数据绑定控件的数据源，在辅助线程（取消第一！），并使用该侦听SystemEvents.User preferenceChanged事件控制（不要在第二个创建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!)

有关参考，相关code是在控制类的静态构造函数present：

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

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

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