Pourquoi une instruction «continue» ne peut-elle pas être dans un bloc «finalement»?

Je n'ai pas de problème; Je suis juste curieux. Imaginez le scénario suivant:

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

Cela ne compilera pas, car cela déclenche l' erreur du compilateur CS0157 :

Le contrôle ne peut pas quitter le corps d'une clause finally

Pourquoi?

finallyles blocs s'exécutent, qu'une exception soit levée ou non. Si une exception est levée, qu'est-ce que diable feraitcontinue ? Vous ne pouvez pas continuer l'exécution de la boucle, car une exception non interceptée transférera le contrôle à une autre fonction.

Même si aucune exception n'est lancée, finally s'exécutera lorsque d'autres instructions de transfert de contrôle à l'intérieur du bloc try / catch s'exécutent, comme returnpar exemple, ce qui pose le même problème.

Bref, avec la sémantique de finally cela n'a pas de sens de permettre le transfert de contrôle de l'intérieur d'un finallybloc vers l'extérieur de celui-ci.

Soutenir cela avec une sémantique alternative serait plus déroutant qu'utile, car il existe des solutions de contournement simples qui clarifient le comportement prévu. Vous obtenez donc une erreur et êtes obligé de bien réfléchir à votre problème. C'est l'idée générale "vous jeter dans le gouffre du succès" qui se poursuit en C #.

Si vous voulez ignorer les exceptions (le plus souvent est une mauvaise idée) et continuer à exécuter la boucle, utilisez un bloc catch all:

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

Si vous ne le souhaitez continueque lorsqu'aucune exception non interceptée n'est levée, mettez simplement en continuedehors du bloc try.

Voici une source fiable:

Une instruction continue ne peut pas quitter un bloc finally (Section 8.10). Lorsqu'une instruction continue se produit dans un bloc finally, la cible de l'instruction continue doit être dans le même bloc finally; sinon, une erreur de compilation se produit.

Il est tiré de MSDN, 8.9.2 L'instruction continue .

La documentation dit que:

Les instructions d'un bloc finally sont toujours exécutées lorsque le contrôle quitte une instruction try. Cela est vrai que le transfert de contrôle se produise à la suite d'une exécution normale, suite à l'exécution d'une instruction break, continue, goto ou return, ou suite à la propagation d'une exception hors de l'instruction try. Si une exception est levée lors de l'exécution d'un bloc finally, l'exception est propagée à l'instruction try englobante suivante. Si une autre exception était en cours de propagation, cette exception est perdue. Le processus de propagation d'une exception est discuté plus loin dans la description de l'instruction throw (section 8.9.5).

C'est d'ici 8.10 L'instruction try .

Vous pensez peut-être que cela a du sens, mais cela n'a pas de sens en fait.

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

Qu'avez-vous l'intention de faire une pause ou une poursuite lorsqu'une exception est levée? L'équipe du compilateur C # ne veut pas prendre de décision par elle-même en supposantbreak ou continue. Au lieu de cela, ils ont décidé de se plaindre que la situation du développeur sera ambiguë pour transférer le contrôle finally block.

C'est donc le travail du développeur d'indiquer clairement ce qu'il a l'intention de faire plutôt que le compilateur en supposant autre chose.

J'espère que vous comprenez pourquoi cela ne compile pas!

Comme d'autres l'ont dit, mais en se concentrant sur les exceptions, il s'agit en réalité d'une gestion ambiguë du transfert de contrôle.

Dans votre esprit, vous pensez probablement à un scénario comme celui-ci:

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

Théoriquement, vous pouvez suivre le flux de contrôle et dire, oui, c'est "ok". Aucune exception n'est levée, aucun contrôle n'est transféré. Mais les concepteurs du langage C # avaient d'autres problèmes en tête.

L'exception lancée

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

Le redouté Goto

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

    pigsfly:
}

Le retour

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

La rupture

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

Donc en conclusion, oui, bien qu'il y ait une légère possibilité d'utiliser un continuedans des situations où le contrôle n'est pas transféré, mais bon nombre (la majorité?) Des cas impliquent des exceptions ou des returnblocages. Les concepteurs de langage ont estimé que cela serait trop ambigu et (probablement) impossible à garantir au moment de la compilation que votre continuen'est utilisé que dans les cas où le flux de contrôle n'est pas transféré.

En général, cela continuen'a pas de sens lorsqu'il est utilisé en finallybloc. Regarde ça:

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

"Cela ne se compilera pas et je pense que c'est tout à fait logique"

Eh bien, je pense que non.

Quand vous l'avez littéralement, catch(Exception)vous n'avez pas besoin de la dernière (et probablement même pas la continue).

Lorsque vous avez le plus réaliste catch(SomeException), que doit-il se passer lorsqu'une exception n'est pas interceptée? Vous continuevoulez aller dans un sens, l'exception en gérant une autre.

Vous ne pouvez pas quitter le corps d'un bloc final. Cela inclut les mots clés break, return et dans votre cas continue.

Le finallybloc peut être exécuté avec une exception en attente d'être relancée. Cela n'aurait pas vraiment de sens de pouvoir sortir du bloc (par uncontinue ou quoi que ce soit d'autre) sans relancer l'exception.

Si vous voulez continuer votre boucle quoi qu'il arrive, vous n'avez pas besoin de l'instruction finally: attrapez simplement l'exception et ne la relancez pas.

finallys'exécute qu'une exception non interceptée soit lancée ou non. D'autres ont déjà expliqué pourquoi cela rend continueillogique, mais voici une alternative qui suit l'esprit de ce que ce code semble demander. Fondamentalement, finally { continue; }c'est dire:

1. Lorsqu'il y a des exceptions interceptées, continuez
2. Lorsqu'il y a des exceptions non interceptées, autorisez-les à être lancées, mais continuez

(1) pourrait être satisfait en plaçant continueà la fin de chacun catch, et (2) pourrait être satisfait en stockant les exceptions non interceptées à lever plus tard. Vous pouvez l'écrire comme ceci:

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

En fait, finallyaurait également exécuté dans le troisième cas, où il n'y avait aucune exception lancée, pris ou non. Si cela était souhaité, vous pourriez bien sûr en placer un continueaprès le bloc try-catch au lieu de l'intérieur de chacun catch.

Techniquement parlant, c'est une limitation du CIL sous-jacent. À partir de la spécification de langue :

Le transfert de contrôle n'est jamais autorisé à entrer un gestionnaire catch ou une clause finally, sauf via le mécanisme de gestion des exceptions.

et

Le transfert de contrôle hors d'une région protégée est autorisé uniquement par le biais d' une instruction d'exception ( leave, end.filter, end.catch, ou end.finally)

Sur la page doc pour les brinstructions :

Les transferts de contrôle vers et depuis les blocs try, catch, filter et finally ne peuvent pas être effectués par cette instruction.

Ce dernier est vrai pour toutes les instructions de branchement, y compris beq, brfalse, etc.

Les concepteurs du langage ne voulaient tout simplement pas (ou ne pouvaient pas) raisonner sur la sémantique d'un bloc finally terminé par un transfert de contrôle.

Un problème, ou peut-être le problème clé, est que le finally bloc est exécuté dans le cadre d'un transfert de contrôle non local (traitement d'exception). La cible de ce transfert de contrôle n'est pas la boucle englobante; le traitement d'exception interrompt la boucle et continue le déroulement.

Si nous avons un transfert de contrôle hors du finally bloc de nettoyage, alors le transfert de contrôle d'origine est "détourné". Il est annulé et le contrôle va ailleurs.

La sémantique peut être élaborée. D'autres langues l'ont.

Les concepteurs de C # ont décidé de simplement interdire les transferts de contrôle statiques, «goto», simplifiant ainsi quelque peu les choses.

Cependant, même si vous faites cela, cela ne résout pas la question de savoir ce qui se passe si un transfert dynamique est lancé à partir d'un finally : que se passe-t-il si le bloc finally appelle une fonction et que cette fonction lève? Le traitement des exceptions d'origine est alors "détourné".

Si vous travaillez sur la sémantique de cette seconde forme de piratage, il n'y a aucune raison de bannir le premier type. C'est vraiment la même chose: un transfert de contrôle est un transfert de contrôle, qu'il ait la même portée lexicale ou non.