原則として、たとえば Herb Sutters C++ Coding Standards (項目 62) で説明されているように、例外はモジュール境界を伝播してはなりません。異なるコンパイラまたはコンパイラ設定だけでコンパイルすると、クラッシュする可能性があります。
たとえば、ダイナミック リンク ライブラリの場合の問題は理解できます。しかし、静的ライブラリにも当てはまるかどうかは疑問です。上記の規則の意味で、静的ライブラリはモジュールですか? ライブラリが他のコンパイラ設定 (アライメントなど) でコンパイルされている場合、静的ライブラリから例外がスローされ、アプリケーションでキャッチされると、プログラムがクラッシュする可能性がありますか?
一般に、静的ライブラリは、成果物（動的ライブラリまたは実行可能ファイル）と互換性を持たせるために、同じコンパイラと同じコンパイラ設定（ほとんど）でコンパイルする必要があります。
次に、静的ライブラリの境界の外側に例外をスローできます。これは、コンパイラが生成した.objファイルのセットとそれほど変わらないためです。そして、明らかに、異なる.objモジュール間で例外をスローすることができます。
編集：
コメントを要約すると：
Herb Sutters の説明も静的ライブラリに適しています。
C++ の例外処理には、ユビキタスなバイナリ標準はありません。両方の側をビルドするために使用されるコンパイラとコンパイラ オプションを制御しない限り、例外が 2 つのコード間で伝播することを許可しないでください。そうしないと、モジュールが例外伝播の互換性のある実装をサポートしない可能性があります。通常、これは次のように要約されます。モジュール/サブシステムの境界を越えて例外が伝播しないようにします。
「モジュール」が何を意味するかによって異なります。そして、問題は例外だけに関係するものではありません。それらは、C++ インターフェイスを使用するあらゆるものに関係する可能性があります。
例外が同じコンポーネントの一部としてコンパイルされたソースの翻訳単位の境界をまたぐ場合、問題はありません。コンポーネント間で、それらがすべて同じアプリケーションの一部であり、それらがすべて同じコンパイラを使用して同じコンパイラ オプションでコンパイルされていることを確認する場合、安全かもしれませんが、動的ライブラリ間を横断するときに問題が発生する可能性があります。ライブラリのロード方法。(一般に、これは、動的にロードされたコンポーネントのシンボルの可視性が動的ローダーに渡されるオプションによって制御される Unix システムでのみ問題になります。) 一般的なルールとして、すべてのアプリケーションを同じオプションでコンパイルするように手配します。コンパイラと同じコンパイラ オプション、また、アプリケーション内で実際に問題が発生することはありません (ただし、少なくとも Unix では、すべての動的コンポーネントが明示的に読み込まれていることを確認する必要がある場合があります)。「外国の」ソフトウェアをロードしている、またはロードされている「アプリケーション」の間では、ハーブの制限は十分ではありません。実際には、アプリケーション間を行き来するインターフェイスは C で定義する必要があります。また、コードのロード方法や、動的にロードされる他のコンポーネントが使用されているかどうかによっては、依然として制限がある場合があります。
静的にリンクすると、ライブラリのロード方法に関する問題が解消されますが、それ以外は何も変わりません。