私は外部のサードパーティのCライブラリを使用するC++ライブラリを作成しています。したがって、私の図書館はこの第三者の図書館の機能を呼び、第三者の図書館は私の図書館の別の部分に電話をかけます。外部リンクCライブラリの例外伝播
この場合、例外はどうなるのでしょうか？ MyLib :: foo（）が最終的にMyLib :: bar（）を呼び出す外部Cライブラリ関数を呼び出し、barが例外をスローすると、どうなりますか？例外はfoo（）のハンドラに正しく伝播されますか？
ありがとう！
例外は、
foo()のハンドラに正しく伝播されますか？
例外が外部Cコードを介して伝播するかどうかは不明です。さらに悪いことに、Cコードは準備ができておらず、例外を処理できません。 Cコードは突然の予期せぬ返品に対して免責する必要はないので、RAIIなどは知らない。
このような状況に直面したとき、私はC APIに戻す前に例外をキャッチして保存した。コールがC APIから戻ってきたときに再び投げた。
これは、重いプラットフォームの実装の詳細です。一般に、例外配管は、C関数のアクティベーションフレームを通してスタックを巻き戻すことができる可能性があります。 CRTはC言語で書かれていることが多いので必要です。しかし、Cコードはそれほど幸せではないでしょう。
これはWindowsの場合、Cコードにはショットがあります。 C++の例外は、構造化例外処理（Structured Exception Handling：SEH）と呼ばれる、Windowsに組み込まれた一般的な例外サポートに抱かれています。 Cコードの状態を復元できる例外フィルタを呼び出すには、__tryおよび__exceptキーワードを使用します。明らかに、これは移植性がありません。
実装の詳細については言及せずに実装の詳細の質問をしないでください。
読むハーブサッターのC++ Coding Standards
＃62（および購入！）： モジュールの境界を越えて を伝播する例外を許可しません。
これは私の答えよりも優れています。私はサードパーティライブラリがC++ではなくCであるとは見ていませんでした。質問者はこれを数回言及しますが。就寝、たぶん。 –
これは正解です。いくつかの実装（GNU）は例外をCコードを越えて伝播させようとしていますが、これを利用するのは非常に非常に難しい**アイデアです。間にCコードが矛盾した状態になることはなく、まだ外部で記録されていない、または解放されていないメモリ割り当てを保持していると仮定する理由はありません。せいぜいあなたはメモリリークを、そして最悪の場合はランダムクラッシュを求めています。私はsbiの問題を回避する方法の提案が好きですが、モジュールの境界を越えて例外を投げないようにするのが最善でしょう。 –
@ Tommy：なぜ、C libを介して例外を伝えるのがあなたの答えに対するコメントとして悪いのか、コメントをコミットしたいときにそれを既に削除してしまったときには悲惨になったのですか？あなたの素晴らしいコメントに感謝します。これはこれを補ってくれました。 '：）' – sbi