'continue'ステートメントを 'finally'ブロック内に配置できないのはなぜですか？

私は問題ありません。気になるだけです。次のシナリオを想像してみてください。

foreach (var foo in list)
{
    try
    {
         //Some code
    }
    catch (Exception)
    {
        //Some more code
    }
    finally
    {
        continue;
    }
}

コンパイラエラーCS0157が発生するため、これはコンパイルされません。

コントロールはfinally句の本体を離れることはできません

どうして？

finallyブロックは、例外がスローされたかどうかに関係なく実行されます。例外がスローされた場合、一体何をcontinueしますか？キャッチされなかった例外は制御を別の関数に移すため、ループの実行を続けることはできません。

例外がスローされない場合でもfinally、try / catchブロック内の他の制御転送ステートメントが実行されると実行されreturnます。たとえば、同じ問題が発生します。

つまり、そのセマンティクスでfinallyは、finallyブロックの内部から外部へ制御を移すことはできません。

意図された動作をより明確にする簡単な回避策があるため、これをいくつかの代替セマンティクスでサポートすると、役立つよりも混乱しやすくなります。したがって、エラーが発生し、問題について適切に考える必要があります。C＃で行われているのは、一般的な「成功の穴に投げ込む」という考えです。

例外を無視して（多くの場合悪い考えです）、ループの実行を続けたい場合は、catch allブロックを使用します。

foreach ( var in list )
{
    try{
        //some code
    }catch{
        continue;
    }
}

continueキャッチされない例外がスローされない場合にのみ使用する場合はcontinue、tryブロックの外側に配置します。

ここに信頼できる情報源があります：

continueステートメントはfinallyブロックを終了できません（セクション8.10）。continueステートメントがfinallyブロック内で発生する場合、continueステートメントのターゲットは同じfinallyブロック内にある必要があります。そうしないと、コンパイル時エラーが発生します。

これは、MSDNの8.9.2から引用されています。

ドキュメントはそれを言う：

finallyブロックのステートメントは、制御がtryステートメントを離れると常に実行されます。これは、通常の実行の結果として、break、continue、goto、またはreturnステートメントの実行の結果として、またはtryステートメントの外に例外を伝播した結果として、コントロール転送が発生する場合にも当てはまります。finallyブロックの実行中に例外がスローされた場合、例外は次の囲んでいるtryステートメントに伝播されます。別の例外が伝搬中だった場合、その例外は失われます。例外を伝播するプロセスについては、throwステートメントの説明（8.9.5節）で詳しく説明しています。

ここからです8.10 tryステートメント。

理にかなっていると思うかもしれませんが、実際には意味がありません。

foreach (var v in List)
{
    try
    {
        //Some code
    }
    catch (Exception)
    {
        //Some more code
        break; or return;
    }
    finally
    {
        continue;
    }
}

例外がスローされたときに、何を中断または継続するつもりですか？C＃コンパイラチームは、breakまたはを想定して自分で決定を下したくありませんcontinue。代わりに、開発者の状況がから制御を移すのは曖昧であると文句を言うことにしましたfinally block。

したがって、コンパイラが何かを想定するのではなく、開発者が何をするつもりかを明確に述べるのは開発者の仕事です。

これがコンパイルされない理由を理解していただければ幸いです！

他の人が述べたように、例外に焦点を当てたように、それはコントロールを移すことの曖昧な処理についてです。

あなたの心の中で、あなたはおそらくこのようなシナリオを考えているでしょう：

public static object SafeMethod()
{
    foreach(var item in list)
    {
        try
        {
            try
            {
                //do something that won't transfer control outside
            }
            catch
            {
                //catch everything to not throw exceptions
            }
        }
        finally
        {
            if (someCondition)
                //no exception will be thrown, 
                //so theoretically this could work
                continue;
        }
    }

    return someValue;
}

理論的には、制御フローを追跡して、はい、これで「大丈夫」と言うことができます。例外はスローされず、コントロールは転送されません。ただし、C＃言語の設計者には他にも問題があった。

スローされた例外

public static void Exception()
{
    try
    {
        foreach(var item in list)
        {
            try
            {
                throw new Exception("What now?");
            }
            finally
            {
                continue;
            }
        }
    }
    catch
    {
        //do I get hit?
    }
}

恐怖の後藤

public static void Goto()
{
    foreach(var item in list)
    {
        try
        {
            goto pigsfly;
        }
        finally
        {
            continue;
        }
    }

    pigsfly:
}

リターン

public static object ReturnSomething()
{
    foreach(var item in list)
    {
        try
        {
            return item;
        }
        finally
        {
            continue;
        }
    }
}

ブレイクアップ

public static void Break()
{
    foreach(var item in list)
    {
        try
        {
            break;
        }
        finally
        {
            continue;
        }
    }
}

したがって、結論として、はい、コントロールが転送されていない状況でaを使用する可能性は少しありますが、多くの場合（大部分？）には例外またはブロックが含まれます。言語設計者は、これが曖昧であり、コンパイル時に制御フローが転送されていない場合にのみ使用されることを確認するのは（おそらく）不可能であると感じました。continuereturncontinue

通常continue、finallyブロックで使用すると意味がありません。これをみて：

foreach (var item in list)
{
    try
    {
        throw new Exception();
    }
    finally{
        //doesn't make sense as we are after exception
        continue;
    }
}

「これはコンパイルされず、完全に理にかなっていると思います」

まあ、そうではないと思います。

あなたが文字通り持っているとき、あなたcatch(Exception)は最終的に（そしておそらくそれさえもcontinue）必要としません。

より現実的なを持っているcatch(SomeException)場合、例外がキャッチされないとどうなりますか？あなたcontinueは一方向に行きたい、例外処理は別のものにしたい。

finallyブロックの本体から離れることはできません。これには、break、return、および場合によってはcontinueキーワードが含まれます。

finallyブロックが再スローされるのを待っている例外で実行することができます。continue例外を再スローせずに（他の何かによって）ブロックを終了できることは、実際には意味がありません。

何が起こってもループを続けたい場合は、finallyステートメントは必要ありません。例外をキャッチし、再スローしないでください。

finallyキャッチされない例外がスローされるかどうかに関係なく実行されます。他の人はこれがなぜcontinue非論理的なのかをすでに説明していますが、このコードが求めているように見えるものの精神に従う代替案があります。基本的にfinally { continue; }は言っています：

1. 例外がキャッチされた場合、続行します
2. キャッチされない例外がある場合、それらがスローされることを許可しますが、引き続き続行します

（1）continue各の最後に配置することで満たすことができcatch、（2）後でスローされるキャッチされない例外を格納することで満たすことができます。次のように書くことができます：

var exceptions = new List<Exception>();
foreach (var foo in list) {
    try {
        // some code
    } catch (InvalidOperationException ex) {
        // handle specific exception
        continue;
    } catch (Exception ex) {
        exceptions.Add(ex);
        continue;
    }
    // some more code
}
if (exceptions.Any()) {
    throw new AggregateException(exceptions);
}

実際にfinallyは、3番目のケースでも実行され、例外がスローされたり、キャッチされたりキャッチされなかったりすることはありませんでした。それが必要な場合は、もちろん、continueそれぞれの内部ではなく、try-catchブロックの後にシングルを配置することもできますcatch。

技術的には、これは基礎となるCILの制限です。言語仕様から：

コントロール転送は、例外処理メカニズムを除いて、catchハンドラーまたはfinally節に入ることが決して許可されていません。

そして

保護された領域のうち制御転送は唯一の例外命令を介して許可された（leave、end.filter、end.catch、またはend.finally）

br手順のドキュメントページ：

この命令では、try、catch、filter、finallyブロックへの制御の転送を実行できません。

この最後はに当てはまる全ての分岐命令を含むbeq、brfalseなど

言語の設計者は、finallyブロックのセマンティクスがコントロールの転送によって終了されることを理由にしたくなかった（またはできなかった）だけでした。

1つの問題、またはおそらく重要な問題は、finallyブロックが一部の非ローカル制御転送（例外処理）の一部として実行されることです。そのコントロール転送のターゲットは、囲んでいるループではありません。例外処理はループを中止し、さらに巻き戻しを続行します。

finallyクリーンアップブロック外のコントロール転送がある場合、元のコントロール転送は「ハイジャック」されています。それは取り消され、制御は別の場所に移動します。

セマンティクスを計算することができます。他の言語にもあります。

C＃の設計者は、静的な「gotoのような」コントロール転送を単に許可しないことを決定しました。

ただし、それを行ったとしても、動的転送がから開始された場合にどうなるかという問題は解決されません。 finallyブロックが関数を呼び出し、その関数がスローした場合はどうなりますか？その後、元の例外処理は「ハイジャック」されます。

このハイジャックの2番目の形式のセマンティクスを理解する場合、最初のタイプを追放する理由はありません。それらは実際には同じものです。コントロール転送は、同じ字句スコープであるかどうかにかかわらず、コントロール転送です。