我在一个用 MSVC 2005 编译的大型多线程应用程序中遇到了一个神秘的崩溃问题。客户端日常使用该应用程序,任何崩溃都会对它们造成重大破坏。我需要一个解决方法。如果我可以将问题隔离到一个功能,并按照以下方式做一些事情:
__try
{
FunctionWhichMayCauseCrash();
}
__except ( [filter expression] )
{
Recover(); // magic - this allows us to prevent crash and continue
}
那么这在理论上对我来说似乎是个好主意。在实践中,有些人(例如这里的拉里奥斯特曼和这里的道格哈里森)认为这可能是一个非常糟糕的主意 - 不应该用驳船杆接触 SEH。
现实检查:我的程序正在生成结构化异常,我不知道在哪里。我正在使用Hans Dietrich 的 XCrashReport 的部分内容——它本身就在使用__try/__except
——试图深入了解这些异常的来源,但到目前为止还没有运气。似乎某些共享资源没有被正确锁定,因此一个线程正在从另一个线程下面拉扯地毯,从而在或多或少随机的地方导致访问冲突。
是否有一个务实的中间立场,这种机制可以防止我的程序崩溃?我是否应该担心我选择的崩溃恢复机制使用了其他人警惕的东西?
澄清:由于程序崩溃造成的极端破坏,我寻求一种防止崩溃的解决方法,而不是最终的永久解决方案。我无意用__try/__except
地毯下的问题扫除。我只是想了解它是否像某些人所说的那样危险,还是应该谨慎使用的合法工具。有些人说话的方式,在我尝试使用定义编译代码的那一刻/EHa
,我的计算机可能会起火。我很想知道人们是否会说使用/EHa
,_set_se_translator
和try/catch(...)
更好,或者等同于同一件事,或者两者是否真的是坏主意。
澄清 2:我不需要帮助调试 :-) 相反,我需要帮助理解混合 SEH 和 C++ 的含义,这似乎在这个论坛和其他论坛上产生的热量多于光。我的低声誉表明论坛的新奇,而不是 C++ 的新奇。我故意将我的应用程序抽象出来,以鼓励人们关注将 SEH 构造引入 C++ 程序的含义。好吧,那是行不通的 :-) 碰巧的是,我的应用程序有一个对象管道,如果我检测到它们中的损坏,我可以很容易地转储其中的任何一个。所以我的神奇Recover()
功能并不像听起来那么神奇,而且很有可能腐败会限制在堆的一小部分。所以......回到问题:使用__try/__except
可取吗?