如果被调用的函数pthread_create
具有以下结构
try{
...code....
pthread_detach(pthread_self());
pthread_exit(NULL);
}catch(...){
std::cout<<"I am here"<<std::endl;
}
为什么省略号的异常处理程序在执行时被调用pthread_exit
?(请注意std::exception
,例如,不会抛出)
如果被调用的函数pthread_create
具有以下结构
try{
...code....
pthread_detach(pthread_self());
pthread_exit(NULL);
}catch(...){
std::cout<<"I am here"<<std::endl;
}
为什么省略号的异常处理程序在执行时被调用pthread_exit
?(请注意std::exception
,例如,不会抛出)
至少在 GCC 中pthread_exit
可能会抛出一个 ___forced_unwind 异常,用于在线程退出期间展开堆栈。它不继承自std::exception
,因此不能被视为一个。如果您确实捕获了该异常,请务必重新throw
处理它,以便它可以完成它的工作:
try {
...
} catch (abi::___forced_unwind&) {
throw;
} catch (...) {
// whatever
}
抛出异常的原因pthread_exit
是指定永远不会返回。让它抛出保证了堆栈分配的变量的清理,并且在它的位置之后不会执行代码(除非你捕捉到展开异常......)。然而,这不是可移植的,例如 Clang 使用了完全不同的机制。
顺便说一句,这是另一个catch (...)
成语弊大于利的情况。它有时用于“稳定”抛出未知异常的代码。但这只会将损害的可见性推迟到以后的时间和地点,从而无法确定问题的真正根源。在这种捕获中唯一合理的做法是最少的清理,可能是记录,然后重新抛出。由于未处理的异常而崩溃的进程并不是一个漂亮的景象,但它可以提供一个可调试的崩溃转储,清楚地显示错误的命令。但这只是我的怨恨,与...catch (...)
几乎没有关系pthread_exit