MSTest - 使用 StackOverflowException 进行单元测试
我用 C# 编写了从命令行调用 MSTest 的程序。 其中一个测试用例抛出 StackOverflowException 并导致 QtAgent32 （和我的应用程序）进程中断。 我可以做什么来防止这种情况（我无法更改单元测试）？
I wrote program in C# that invokes MSTest from command line.
One of test cases throws StackOverflowException and it causes, that QtAgent32 (and my application) process breaks.
What can I do to prevent from this situation (I can't change unit tests)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
避免此类崩溃的一种方法是在 QTAgent32.exe.config（和/或 QTAgent.exe.config，具体取决于计算机/测试运行的位数）中设置legacyUnhandledExceptionPolicy 属性，如所述 此处。此链接中的相关文本是： -
作为临时兼容性措施，管理员可以在应用程序配置文件的部分中放置兼容性标志。这会导致公共语言运行时恢复到版本 1.0 和 1.1 的行为。
这会将“未处理的异常”处理行为切换到 .net 1.1，并且进程不会在此类情况下崩溃例外情况。
One way by which you can avoid these kind of crashes is by setting the legacyUnhandledExceptionPolicy property in QTAgent32.exe.config (and/or QTAgent.exe.config depending upon the bitness of the machine/testrun) as mentioned here. Relevant text from this link is: -
As a temporary compatibility measure, administrators can place a compatibility flag in the section of the application configuration file. This causes the common language runtime to revert to the behavior of versions 1.0 and 1.1.
This will switch the "unhandled exception" handling behaviour to .net 1.1 and the process will not crash on such exceptions.
问题是您无法在 .NET 上捕获 StackOverflowException（从 2.0 版本开始）。这可能意味着无法解决您遇到的问题 - 因为单元测试框架根本无法捕获异常。
请参阅以下相关 SO 问题：
关于其他线程有一些有趣的建议 - 例如，您可以创建 Thread 并检查当前的 FrameCount 以尽早检测堆栈溢出。然而，这可能不太可靠。所以，恐怕没有什么好的答案......
The problem is that you cannot catch
StackOverflowExceptionon .NET (starting with the 2.0 version). This probably means that there is no way to solve the problem you have - because the unit testing framework simply cannot catch the exception.See the following related SO question:
There are some interesting suggestions on the other thread - for example, you can create
Threadand check the currentFrameCountto detect the stack overflow earlier. However, that probably won't be very reliable. So, I'm afraid there is no good answer...