为什么“ 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在未引发任何未捕获的异常的情况下，只需将其放在continuetry块之外。

这是可靠的来源：

继续语句不能退出finally块（第8.10节）。当在finally块内出现continue语句时，continue语句的目标必须在相同的finally块内。否则，将发生编译时错误。

它取自MSDN，8.9.2继续声明。

该文件说：

当控制离开try语句时，总是执行finally块的语句。无论是由于正常执行，由于执行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;
        }
    }
}

所以在最后，是的，虽然是一个轻微使用的可能性，continue在控制不被转移的情况，但一个很好的协议的情况下（多数？）涉及异常或return块。语言设计人员认为这将太含糊，并且（很可能）无法确保在编译时仅在不传输控制流的情况下continue使用您的语言。

通常continue，在finally块中使用时没有任何意义。看看这个：

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

“这不会编译，我认为这完全有道理”

好吧，我认为不是。

当您真正拥有时，catch(Exception)则不需要final（甚至可能不需要continue）。

如果您比较现实catch(SomeException)，那么在未捕获异常的情况下应该怎么办？您continue想采用一种方式，而异常处理则采用另一种方式。

您不能离开finally块的主体。这包括break，return和您可能的continue关键字。

finally可以执行该块，但有一个等待重新抛出的异常。能够（不通过a 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在第三种情况下也将执行，在这种情况下，根本不会引发任何异常，无论是捕获还是未捕获。如果需要的话，您当然可以continue在try-catch块之后放置一个，而不是在每个内部放置一个catch。

从技术上讲，这是对基础CIL的限制。根据语言规范：

除非通过异常处理机制，否则不允许控制传递进入catch处理程序或finally子句。

和

控制转移出一个受保护的区域的仅通过一个异常指令允许（leave，end.filter，end.catch，或end.finally）

在针对该文档页面br指令：

该指令无法执行控制进出try，catch，filter和finally块的操作。

这最后看到真正的所有分支指令，包括beq，brfalse等

该语言的设计者根本不想（或无法）推断由控制传递终止的finally块的语义。

一个问题，或者可能是关键问题，是该finally块作为某些非本地控制传输（异常处理）的一部分执行。控制传递的目标不是封闭循环；异常处理将中止循环并继续展开。

如果我们有finally清除块之外的控制转移，则原始的控制转移被“劫持”。它被取消，控制权移到其他地方。

语义可以解决。其他语言也有。

C＃的设计人员决定简单地禁止静态的，类似于“ goto”的控件传输，从而在某种程度上简化了事情。

但是，即使您这样做，也不能解决以下问题finally：如果从a启动动态传输，将会发生什么：如果finally块调用了一个函数，并且该函数引发了该怎么办？然后将原始异常处理“劫持”。

如果弄清了第二种劫持形式的语义，则没有理由取消第一种劫持。它们实际上是同一回事：控件转移就是控件转移，无论其词法作用域是否相同。