为什么 Visual Studio 在运行单元测试时会因无人处理的异常而中断？
也许有人能够解释为什么我在运行单元测试时遇到未处理的异常？环境不应该处理所有异常并将测试设置为失败吗？
这可能与单元测试通过 C++/CLI 调用非托管代码这一事实有关？
提前致谢。
编辑：只是为了澄清，问题不在于有例外。问题是异常没有导致单元测试失败并要执行下一个单元测试。
maybe someone is able to explain me why I'm having unhandled exceptions when running unit tests? Is not supposed the environment to handle all the exceptions and just set the test to failed?
This can be related to the fact that the unit tests are calling unmanaged code thru C++/CLI?
Thanks in advance.
EDIT: Just to clarify, the problem is not having an exception. The problem is the exception not causing the unit test to fail and going to execute the next unit test.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
没有什么比 AccessViolation 异常更令人讨厌的了，只有 StackOverflow 更糟糕。我可以看出“通信”，即非托管代码可能在 CLR 和测试运行程序都不知道的线程中运行。那里的选择非常有限，没有办法让这样的线程简单地抓住存在。
这是一个内存损坏问题，CRT 中的调试分配器用 0xfeeefeee 填充已释放的内存块。顺便说一句，这不是犹太洁食，您应该只在发布版本上运行单元测试。
There's nothing quite as nasty as an AccessViolation exception, only StackOverflow is worse. I can make out "communication", that unmanaged code probably runs in a thread that neither the CLR nor the test runner knows anything about. Very limited options there, no way to make a thread like that simply seize to exist.
It's a memory corruption problem, the debug allocator in the CRT fills freed blocks of memory with 0xfeeefeee. That's not kosher btw, you should only run unit tests on the Release build.