Por que uma instrução 'continue' não pode estar dentro de um bloco 'finalmente'?

Eu não tenho um problema; Eu só estou curioso. Imagine o seguinte cenário:

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

Isso não compila, pois gera o erro do compilador CS0157 :

O controle não pode deixar o corpo de uma cláusula finalmente

Por quê?

finallyos blocos são executados quer uma exceção seja lançada ou não Se uma exceção for lançada, o que diabos faria continue? Você não pode continuar a execução do loop, porque uma exceção não capturada transferirá o controle para outra função.

Mesmo que nenhuma exceção seja lançada, finallyserá executado quando outras instruções de transferência de controle dentro do bloco try / catch forem executadas, como um return, por exemplo, que traz o mesmo problema.

Em suma, com a semântica finallydisso, não faz sentido permitir a transferência de controle de dentro de um finallybloco para fora dele.

Apoiar isso com alguma semântica alternativa seria mais confuso do que útil, uma vez que existem soluções alternativas simples que tornam o comportamento pretendido muito mais claro. Assim, você obtém um erro e é forçado a pensar corretamente sobre o problema. É a ideia geral de "jogar você no poço do sucesso" que existe no C #.

Se você deseja ignorar as exceções (na maioria das vezes é uma má ideia) e continuar executando o loop, use um bloco catch all:

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

Se você quiser continueapenas quando nenhuma exceção não detectada for lançada, basta colocar continuefora do bloco try.

Aqui está uma fonte confiável:

Uma instrução continue não pode sair de um bloco finally (Seção 8.10). Quando uma instrução continue ocorre dentro de um bloco finally, o destino da instrução continue deve estar dentro do mesmo bloco finally; caso contrário, ocorrerá um erro em tempo de compilação.

Ele é retirado do MSDN, 8.9.2 A instrução continue .

A documentação diz que:

As instruções de um bloco finally são sempre executadas quando o controle sai de uma instrução try. Isso é verdade se a transferência de controle ocorre como resultado da execução normal, como resultado da execução de uma instrução break, continue, goto ou return, ou como resultado da propagação de uma exceção da instrução try. Se uma exceção for lançada durante a execução de um bloco finally, a exceção será propagada para a próxima instrução try envolvente. Se outra exceção estiver em processo de propagação, essa exceção será perdida. O processo de propagação de uma exceção é discutido posteriormente na descrição da instrução throw (Seção 8.9.5).

É a partir daqui 8.10 A instrução try .

Você pode pensar que faz sentido, mas não faz sentido na verdade.

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

O que você pretende interromper ou continuar quando uma exceção for lançada? A equipe do compilador C # não quer tomar decisões por conta própria assumindo breakou continue. Em vez disso, eles decidiram reclamar que a situação do desenvolvedor seria ambígua para transferir o controle finally block.

Portanto, é função do desenvolvedor declarar claramente o que ele pretende fazer, em vez de o compilador assumir outra coisa.

Espero que você entenda porque isso não compila!

Como outros afirmaram, mas com foco nas exceções, trata-se realmente de um tratamento ambíguo da transferência de controle.

Em sua mente, você provavelmente está pensando em um cenário como este:

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;
}

Teoricamente, você pode rastrear o fluxo de controle e dizer, sim, isso é "ok". Nenhuma exceção é lançada, nenhum controle é transferido. Mas os designers da linguagem C # tinham outros problemas em mente.

A exceção lançada

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

The Dreaded Goto

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

    pigsfly:
}

O retorno

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

A separação

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

Portanto, em conclusão, sim, enquanto não é uma ligeira possibilidade de usar uma continueem situações onde o controle não está sendo transferido, mas um bom negócio (maioria?) Dos casos envolvem exceções ou returnblocos. Os designers da linguagem acharam que isso seria muito ambíguo e (provavelmente) impossível de garantir no momento da compilação que o seu continueseja usado apenas nos casos em que o fluxo de controle não está sendo transferido.

Em geral continue, não faz sentido quando usado em finallybloco. Dê uma olhada neste:

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

"Isso não vai compilar e acho que faz todo o sentido"

Bem, acho que não.

Quando você literalmente tem, catch(Exception)então você não precisa do finalmente (e provavelmente nem mesmo do continue).

Quando você tiver o mais realista catch(SomeException), o que deve acontecer quando uma exceção não for detectada? Você continuequer ir para um lado, a exceção tratando de outro.

Você não pode deixar o corpo de um bloco final. Isso inclui pausa, retorno e, no seu caso, continuar palavras-chave.

O finallybloco pode ser executado com uma exceção aguardando para ser relançado. Realmente não faria sentido poder sair do bloco (por um continueou qualquer outra coisa) sem relançar a exceção.

Se você quiser continuar seu loop, aconteça o que acontecer, você não precisa da instrução finally: apenas capture a exceção e não lance novamente.

finallyé executado quer uma exceção não capturada seja lançada ou não. Outros já explicaram por que isso torna continueilógico, mas aqui está uma alternativa que segue o espírito do que este código parece estar pedindo. Basicamente, finally { continue; }está dizendo:

1. Quando houver exceções detectadas, continue
2. Quando houver exceções não detectadas, permita que sejam lançadas, mas continue

(1) poderia ser satisfeito colocando continueno final de cada um catch, e (2) poderia ser satisfeito armazenando exceções não capturadas para serem lançadas posteriormente. Você poderia escrever assim:

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);
}

Na verdade, finallytambém teria sido executado no terceiro caso, onde não houve exceções lançadas, capturadas ou não capturadas. Se isso for desejado, você pode, é claro, colocar um único continuebloco após o bloco try-catch em vez de dentro de cada um catch.

Tecnicamente falando, é uma limitação do CIL subjacente. Da especificação de idioma :

A transferência de controle nunca tem permissão para inserir um manipulador catch ou cláusula finally, exceto por meio do mecanismo de tratamento de exceção.

e

Transferir o controlo de uma região protegida apenas é permitida através de uma instrução de excepção ( leave, end.filter, end.catch, ou end.finally)

Na página doc para obter as brinstruções :

As transferências de controle para dentro e fora dos blocos try, catch, filter e finalmente não podem ser executadas por esta instrução.

Este último é válido para todas as instruções de desvio, incluindo beq, brfalse, etc.

Os designers da linguagem simplesmente não queriam (ou não podiam) raciocinar sobre a semântica de um bloco final sendo encerrado por uma transferência de controle.

Um problema, ou talvez o principal, é que o finallybloco é executado como parte de alguma transferência de controle não local (processamento de exceção). O alvo dessa transferência de controle não é o loop envolvente; o processamento da exceção aborta o loop e continua a se desenrolar ainda mais.

Se tivermos uma transferência de controle fora do finallybloco de limpeza, a transferência de controle original está sendo "sequestrada". Ele é cancelado e o controle vai para outro lugar.

A semântica pode ser resolvida. Outras línguas têm.

Os projetistas do C # decidiram simplesmente não permitir transferências de controle estáticas do tipo "goto", simplificando um pouco as coisas.

No entanto, mesmo se você fizer isso, não resolverá a questão do que acontece se uma transferência dinâmica for iniciada de a finally: e se o bloco finally chamar uma função e essa função lançar? O processamento da exceção original é então "sequestrado".

Se você resolver a semântica dessa segunda forma de sequestro, não há razão para banir o primeiro tipo. Eles são realmente a mesma coisa: uma transferência de controle é uma transferência de controle, seja do mesmo escopo lexical ou não.