Чому вислів "продовження" не може знаходитись у блоці "нарешті"?

У мене немає проблем; Мені просто цікаво. Уявіть такий сценарій:

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

Це не компілюється, оскільки це призводить до помилки компілятора CS0157 :

Контроль не може залишити остаточне застереження

Чому?

finallyблоки запускаються, викинутий виняток чи ні. Якщо викинутий виняток, що б чорт continueробив? Ви не можете продовжувати виконання циклу, оскільки нездійснене виключення передасть управління іншій функції.

Навіть якщо не буде винято жодного винятку, finallyвін запускається, коли інші оператори передачі управління всередині запуску блоку спробу / лову, як return, наприклад, викликає ту ж проблему.

Коротше кажучи, з семантикою finallyне має сенсу допускати передачу контролю зсередини finallyблоку на зовнішній його.

Підтримка цього за допомогою альтернативної семантики було б більш заплутаною, ніж корисною, оскільки існують прості шляхи вирішення, які роблять зрозуміліший спосіб поведінки. Тож ви отримуєте помилку і змушені правильно думати над своєю проблемою. Це загальна ідея "кинути тебе в яму успіху", яка продовжується в C #.

Якщо ви хочете ігнорувати винятки (частіше за все це погана ідея) і продовжувати виконувати цикл, використовуйте блок catch all:

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

Якщо ви хочете continueлише тоді, коли не викидаються вилучені винятки, просто поставте continueза межі пробного блоку.

Ось надійне джерело:

Оператор продовження не може вийти з остаточно блоку (Розділ 8.10). Коли оператор продовження відбувається в остаточному блоці, ціль оператора продовження повинна знаходитися в межах одного остаточного блоку; в іншому випадку виникає помилка часу компіляції.

Це взято з MSDN, 8.9.2. Продовження .

У документації сказано, що:

Висловлювання остаточно блоку завжди виконуються, коли контроль залишає спробу оператора. Це вірно, чи передача керування відбувається в результаті звичайного виконання, в результаті виконання перерви, продовження, переходу або повернення, або в результаті розповсюдження виключення з оператора спробу. Якщо виняток буде кинуто під час виконання остаточного блоку, виняток поширюється на наступне додане спробу оператора. Якщо інший виняток був у процесі поширення, цей виняток втрачається. Процес розповсюдження винятку обговорюється далі в описі заяви викидання (Розділ 8.9.5).

Це звідси 8.10 Спроба твердження .

Ви можете подумати, що це має сенс, але насправді це не має сенсу .

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)то вам нарешті не потрібен (і, мабуть, навіть не той continue).

Якщо у вас є більш реалістичний catch(SomeException), що має статися, коли виняток не буде спійманий? Ви continueхочете піти в один бік, виняток - керувати іншим.

Ви не можете залишити корпус остаточно блоку. Це включає перерву, повернення і у вашому випадку продовжуйте ключові слова.

finallyБлок може бути виконаний з виключенням чекати , щоб бути викликані повторно. Насправді не було б сенсу мати можливість вийти з блоку ( continueабо іншим), не скидаючи виняток.

Якщо ви хочете продовжувати цикл, що б не трапилося, вам не потрібно остаточного твердження: Просто вловіть виняток і не перекидайте.

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після блоку спробу лову, а не всередині кожного catch.

Технічно кажучи, це обмеження основної CIL. З мовної специфікації :

Передача управління ніколи не дозволяється вводити обробник лову або остаточно ставитись за винятком випадків, за допомогою механізму обробки винятків.

і

Передача управління з захищеної області дозволяється тільки через інструкцію виключення ( leave, end.filter, end.catchабо end.finally)

На сторінці документа для brвказівки :

Ця інструкція не може виконувати передачу елементів керування в і випробовувати, ловити, фільтрувати та, нарешті, блоки.

Останнє справедливо для всіх галузевих інструкцій, в тому числі beq, brfalseі т.д.

Дизайнери мови просто не хотіли (або не могли) міркувати про семантику остаточного блоку, що закінчується передачею управління.

Одне питання, чи, можливо, ключове, полягає в тому, що finallyблок виконується як частина передачі нелокального контролю (обробка виключень). Ціль передачі управління - це не цикл, що охоплює; обробка виключення скасовує цикл і продовжує розкручуватися далі.

Якщо у нас передача керування вийшла з finallyблоку очищення, то початкова передача управління "викрадена". Він скасовується, а контроль йде в іншому місці.

Семантику можна опрацювати. Інші мови мають його.

Дизайнери C # вирішили просто заборонити статичні "готоподібні" передачі управління, тим самим дещо спростивши речі.

Однак, навіть якщо ви це зробите, це не вирішує питання про те, що відбувається, якщо динамічна передача ініціюється з а finally: що робити, якщо нарешті блок викликає функцію, і ця функція кидає? Оригінальну обробку винятків потім "викрадено".

Якщо ви відпрацьовуєте семантику цієї другої форми викрадення, немає ніяких причин виганяти перший тип. Вони насправді те саме: передача управління - це передача керування, незалежно від того, лексична вона чи ні.