TIL RAII とスタック巻き戻しの「絡み合い」(より適切な言葉がないため) の私の概念は、(完全ではないにしても) かなり間違っています。私の理解では、RAII を使用すると、未処理の例外が原因である可能性があるものであっても、あらゆる/すべてのリソース リークを防ぐことができます。
ただし、このテスト プログラムを作成し、その後この記事/ドキュメントに出くわしたことで、スタックの巻き戻しは、たとえば、外部/その他のスコープ内の自動ではなく、try ブロック内の自動リソースに対してのみ、RAII 対応のリソースの割り当て解除が開始されることに気付きました。 .
この（新しい）理解は正しいですか？それとも、私がまだ把握していないニュアンスがありますか? そこにチャイムを鳴らしたいグルはいますか？適切な記事/分析/説明 (スタックの巻き戻しの) へのポインタは、役に立ちます/高く評価されます…</p>
C ++ 03標準から、§15.3/ 9：
プログラムに一致するハンドラーが見つからない場合、関数terminate（）が呼び出されます。このterminate（）の呼び出しが実装定義（15.5.1）される前に、スタックが巻き戻されるかどうか。
§15.5.1/1：
次の状況では、より微妙なエラー処理手法のために例外処理を破棄する必要があります。...例外処理メカニズムがスローされた例外のハンドラーを見つけられない場合（15.3）.. ..
§15.5.1/2：
このような場合、
voidterminate（）;
（18.6.3）と呼ばれます。一致するハンドラーが見つからない状況では、terminate（）が呼び出される前にスタックがアンワインドされるかどうかが実装によって定義されます。他のすべての状況では、terminate（）が呼び出される前にスタックが巻き戻されてはなりません。実装は、アンワインドプロセスが最終的にterminate（）の呼び出しを引き起こすという決定に基づいて、スタックのアンワインドを途中で終了することは許可されていません。
throw some_exceptionからへの途中で「スタックの巻き戻し」が発生するのは正しいですcatch(some_exception)。例外がキャッチに到達しない場合、何が起こるかわかりません。
それは大きな問題ですか？あなた自身が示したように、catch(...)考えられるすべての例外をキャッチするためにどこかに追加するだけで、問題は解決します。