少なくともGCCではpthread_exit
、___ forced_unwind例外がスローされる可能性があります。これは、スレッドの終了時にスタックを巻き戻すために使用されます。から継承しないためstd::exception
、1つとしてキャッチすることはできません。その例外をキャッチした場合は、必ず再throw
実行して、その機能を実行できるようにしてください。
try {
...
} catch (abi::___forced_unwind&) {
throw;
} catch (...) {
// whatever
}
例外がスローされる理由は、pthread_exit
決して戻らないように指定されているためです。スローすることで、スタックに割り当てられた変数のクリーンアップが保証され、その場所の後にコードが実行されなくなります(アンワインド例外をキャッチしない限り...)。ただし、これは移植性がなく、たとえばClangはまったく異なるメカニズムを使用します。
catch (...)
ところで、これはイディオムが善よりも害を及ぼすもう1つのケースです。未知の例外をスローしているコードを「安定化」するために使用されることがあります。しかし、それは損傷の可視性を後の時間と場所に延期するだけであり、問題の本当の原因を特定することは不可能です。このようなキャッチで行う唯一の合理的なことは、最小限のクリーンアップ、場合によってはログ記録、そして再スローです。未処理の例外が原因でクラッシュするプロセスは見た目がよくありませんが、エラーのあるコマンドを明確に示すデバッグ可能なクラッシュダンプを提供できます。しかし、それは私の恨みでcatch (...)
あり、ほとんど関係がありませんpthread_exit
...