ブレーク/継続/リターンは例外によって中断されるべきですか？

Question

自分の言語で作業しているときに、フロー制御で面白いシナリオが発生しました。 breakステートメントの処理中に例外がスローされた場合はどうなりますか。 GCCはブレークフローが失われたと信じているようだが、標準は何が起こるべきかについていくらか沈黙しているようだ。

例えば、次のプログラムは実際に何をすべきですか？

#include <iostream> 
using namespace std; 

struct maybe_fail { 
    bool fail; 
    ~maybe_fail() { 
     if(fail) 
      throw 1; 
    } 
}; 

int main() { 
    for(int i=0; i < 6; ++i) { 
     cout << "Loop: " << i << endl; 

     try { 
      maybe_fail mf; 
      mf.fail = i % 2; 
      if(i == 3) 
       break; 

     } catch(int) { 
      cout << "Caught" << endl; 
     } 
    } 
    return 0; 
} 

continueが（それを見てキャッチした後、出力を追加）されますようreturnも、ブロックされることに注意してください。ブロックの外にgotoへの試みもキャッチされます。

正しいフローは何ですか？標準はこれに対処していないようです：jump文のセクション6.6は言及しません。また、例外処理のセクション15も言及しません。デストラクタの例外はひどく悪いものですが、BOOST_SCOPE_EXITのようなものをdefer文に使用している場合は、この動作が非常に重要になる可能性があります。

おそらく、JavaとPythonでは同じ流れが起こるため、命令型言語には一貫性があるようです。

Answer 1

がこれは例外をスロー15.1で覆われている：例外がスローされる場合

2、制御は、整合型（15.3）と最も近いハンドラに転送されます。 "nearest"は、tryキーワード に続くcompound-statementまたはctor-initializerが、制御スレッドによって最後に入力されたがまだ終了していないハンドラを意味します。

制御が例外ハンドラに転送されると、そこから制御が移ります。コードがbreakの真中にあったことを「覚えて」いるメカニズムはなく、何らかの形で例外が処理された後にコードが再開されます。

Answer 2

スタンドナードの具体的な文言に拘らず、私はそれがあいまいだと言うつもりです。テキストは、これらの状況を意図するフローを特定するのに不十分である。私たちが現在行っているコンベンションは、コンパイラがどのように書かれているかに起因するものです。

私のブログトピックHow to catch a "return" statementを参照してください。