Dlaczego instrukcja „kontynuuj” nie może znajdować się wewnątrz bloku „na koniec”?

Nie mam problemu; Jestem po prostu ciekawy. Wyobraź sobie następujący scenariusz:

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

To się nie skompiluje, ponieważ powoduje błąd kompilatora CS0157 :

Kontrola nie może opuścić treści klauzuli końcowej

Czemu?

finallybloki są uruchamiane niezależnie od tego, czy został zgłoszony wyjątek, czy nie. Co by się stało, gdyby został wyrzucony wyjątek continue? Nie można kontynuować wykonywania pętli, ponieważ nieprzechwycony wyjątek przeniesie kontrolę do innej funkcji.

Nawet jeśli nie zostanie zgłoszony żaden wyjątek, finallyzostanie uruchomiony, gdy inne instrukcje transferu sterującego w przebiegu bloku try / catch, takie jak returnna przykład a, powodują ten sam problem.

Krótko mówiąc, z jego semantyką finallynie ma sensu zezwalanie na przenoszenie kontroli z wnętrza finallybloku na zewnątrz.

Wspieranie tego za pomocą alternatywnej semantyki byłoby bardziej zagmatwane niż pomocne, ponieważ istnieją proste obejścia, które sprawiają, że zamierzone zachowanie jest wyraźniejsze. Otrzymujesz więc błąd i jesteś zmuszony do prawidłowego przemyślenia swojego problemu. Jest to ogólna idea „rzucenia się w dół sukcesu”, która pojawia się w C #.

Jeśli chcesz zignorować wyjątki (najczęściej jest to zły pomysł) i kontynuować wykonywanie pętli, użyj bloku catch all:

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

Jeśli chcesz continuetylko wtedy, gdy nie są wyrzucane żadne nieprzechwycone wyjątki, po prostu umieść continuepoza blokiem try.

Oto wiarygodne źródło:

Instrukcja continue nie może wyjść z bloku final (sekcja 8.10). Gdy instrukcja continue występuje w bloku final, cel instrukcji continue musi znajdować się w tym samym bloku final; w przeciwnym razie wystąpi błąd w czasie kompilacji.

Pochodzi z MSDN, 8.9.2 Instrukcja continue .

Dokumentacja mówi, że:

Instrukcje bloku last są zawsze wykonywane, gdy sterowanie opuszcza instrukcję try. Dzieje się tak niezależnie od tego, czy przekazanie kontroli następuje w wyniku normalnego wykonania, w wyniku wykonania instrukcji break, continue, goto lub return, czy też w wyniku propagowania wyjątku z instrukcji try. Jeśli wyjątek zostanie zgłoszony podczas wykonywania ostatniego bloku, wyjątek jest propagowany do następnej otaczającej instrukcji try. Jeśli propagowano inny wyjątek, zostanie on utracony. Proces propagowania wyjątku omówiono dalej w opisie instrukcji throw (sekcja 8.9.5).

Jest stąd 8.10 Instrukcja try .

Możesz myśleć, że to ma sens, ale w rzeczywistości nie ma to sensu .

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

Co zamierzasz zrobić przerwę lub kontynuować, gdy zostanie zgłoszony wyjątek? Zespół kompilatora C # nie chce samodzielnie podejmować decyzji, zakładając breaklub continue. Zamiast tego postanowili poskarżyć się, że sytuacja dewelopera będzie niejednoznaczna do przekazania kontroli finally block.

Zatem zadaniem programisty jest jasne określenie, co zamierza zrobić, zamiast zakładania przez kompilator czegoś innego.

Mam nadzieję, że rozumiesz, dlaczego to się nie kompiluje!

Jak stwierdzili inni, ale skupili się na wyjątkach, tak naprawdę chodzi o niejednoznaczne traktowanie przekazywania kontroli.

Myślisz prawdopodobnie o takim scenariuszu:

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

Teoretycznie można prześledzić przepływ sterowania i powiedzieć, że tak, to jest „ok”. Żaden wyjątek nie jest zgłaszany, nie jest przekazywana żadna kontrola. Ale projektanci języka C # mieli na myśli inne problemy.

Wyrzucony wyjątek

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

Dreaded Goto

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

    pigsfly:
}

Powrót

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

Zerwanie

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

Tak na zakończenie, tak, natomiast nie jest niewielkie możliwość użycia continuew sytuacjach, gdy kontrola nie jest przekazywana, ale sporo (większość?) Przypadków dotyczyć wyjątki lub returnbloków. Projektanci języka uznali, że byłoby to zbyt niejednoznaczne i (prawdopodobnie) niemożliwe do zapewnienia w czasie kompilacji, że Twój continuejest używany tylko w przypadkach, gdy przepływ sterowania nie jest przenoszony.

Generalnie continuenie ma sensu, gdy jest używany w finallybloku. Spójrz na to:

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

„To się nie skompiluje i myślę, że ma to sens”

Myślę, że tak nie jest.

Kiedy dosłownie masz catch(Exception), nie potrzebujesz wreszcie (i prawdopodobnie nawet nie continue).

Jeśli masz bardziej realistyczne catch(SomeException)podejście, co powinno się stać, gdy wyjątek nie zostanie przechwycony? Twoje continuechce jechać w jedną stronę, wyjątek obsługi drugiego.

Nie możesz opuścić ciała ostatecznego bloku. Obejmuje to łamanie, powrót, aw Twoim przypadku kontynuowanie słów kluczowych.

finallyBlok może być wykonany z wyjątkiem czeka na rethrown. Naprawdę nie miałoby sensu opuszczanie bloku (przez a continuelub cokolwiek innego) bez ponownego zgłaszania wyjątku.

Jeśli chcesz kontynuować pętlę cokolwiek się stanie, nie potrzebujesz instrukcji final: po prostu złap wyjątek i nie wyrzucaj ponownie.

finallydziała niezależnie od tego, czy zostanie zgłoszony nieprzechwycony wyjątek. Inni już wyjaśnili, dlaczego jest to continuenielogiczne, ale tutaj jest alternatywa, która jest zgodna z duchem tego, o co wydaje się prosić ten kod. Zasadniczo finally { continue; }mówi:

1. W przypadku wykrycia wyjątków kontynuuj
2. Jeśli są nieprzechwycone wyjątki, pozwól im zostać wyrzucone, ale kontynuuj

(1) można zadowalać umieszczając continuena końcu każdego z nich catch, a (2) zadowalać przechowywanie nieprzechwyconych wyjątków do późniejszego wyrzucenia. Możesz to napisać tak:

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

W rzeczywistości finallyzostałby stracony również w trzecim przypadku, w którym nie było żadnych wyjątków, złapanych lub nie złapanych. Jeśli było to pożądane, możesz oczywiście po prostu umieścić pojedynczy znak continuepo bloku try-catch zamiast wewnątrz każdego catch.

Technicznie rzecz biorąc, jest to ograniczenie podstawowego CIL. Ze specyfikacji językowej :

Transfer kontroli nigdy nie jest dozwolony do wprowadzenia procedury obsługi catch lub klauzuli last, chyba że za pośrednictwem mechanizmu obsługi wyjątków.

i

Przekazanie sterowania z chronionego obszaru jest dozwolona wyłącznie przez instrukcji wyjątków ( leave, end.filter, end.catch, a end.finally)

Na stronie z brinstrukcją :

Ta instrukcja nie pozwala na wykonywanie transferów kontrolnych do bloków try, catch, filter, i na końcu.

To ostatnie odnosi się do wszystkich instrukcji branżowych, w tym beq, brfalseitp

Projektanci języka po prostu nie chcieli (lub nie mogli) rozumować semantyki ostatecznego bloku zakończonego transferem sterującym.

Jednym z problemów, a może kluczowym, jest to, że finallyblok jest wykonywany jako część nielokalnego transferu sterowania (przetwarzanie wyjątków). Celem tego transferu kontroli nie jest otaczająca pętla; przetwarzanie wyjątku przerywa pętlę i kontynuuje rozwijanie.

Jeśli mamy transfer kontroli z finallybloku porządkowego, to pierwotny transfer kontroli jest „przechwytywany”. Zostaje anulowane, a kontrola idzie gdzie indziej.

Można wypracować semantykę. Mają to w innych językach.

Projektanci C # zdecydowali się po prostu nie zezwalać na statyczne przenoszenie elementów sterujących typu „goto”, co nieco uprościło pewne czynności.

Jednak nawet jeśli to zrobisz, nie rozwiąże to pytania, co się stanie, jeśli transfer dynamiczny zostanie zainicjowany z a finally: a co, jeśli ostatni blok wywoła funkcję, a ta funkcja wyrzuca? Oryginalne przetwarzanie wyjątków jest następnie „przechwytywane”.

Jeśli poznasz semantykę tej drugiej formy przechwytywania, nie ma powodu, aby odrzucać pierwszy typ. W rzeczywistości są tym samym: przekazanie kontroli jest przekazem kontroli, niezależnie od tego, czy ma ten sam zakres leksykalny, czy nie.