Почему в C ++ нет конструкции finally?

Обработка исключений в C ++ ограничена попыткой / throw / catch. В отличие от Object Pascal, Java, C # и Python, даже в C ++ 11 finallyконструкция не была реализована.

Я видел очень много литературы по С ++, обсуждающей «код, исключающий исключение». Липпман пишет, что безопасный код исключений - это важная, но сложная и трудная тема, выходящая за рамки его учебника, из которого следует, что безопасный код не является фундаментальным для C ++. Херб Саттер посвящает 10 глав этой теме в своем «Исключительном C ++»!

Тем не менее, мне кажется, что многие проблемы, возникающие при попытке написать «безопасный код для исключения», могли бы быть достаточно хорошо решены, если бы finallyбыла реализована конструкция, позволяющая программисту гарантировать, что даже в случае исключения программа может быть восстановлена. в безопасное, стабильное состояние без утечек, близкое к точке выделения ресурсов и потенциально проблемного кода. Как очень опытный программист на Delphi и C #, я использую try ... finally довольно широко блокирует мой код, как и большинство программистов на этих языках.

Рассматривая все «навороты», реализованные в C ++ 11, я был удивлен, обнаружив, что «наконец-то» все еще не было.

Итак, почему finallyконструкция никогда не была реализована в C ++? Это действительно не очень сложная или продвинутая концепция для понимания, и она помогает программисту писать «безопасный для исключений код».

В качестве дополнительного комментария к ответу @ Nemanja (который, поскольку он цитирует Страуструпа, на самом деле такой же хороший ответ, как вы можете получить):

Это просто вопрос понимания философии и идиом языка C ++. Возьмите пример операции, которая открывает соединение с базой данных в постоянном классе и должна убедиться, что оно закрывает это соединение, если выдается исключение. Это вопрос безопасности исключений и применяется к любому языку с исключениями (C ++, C #, Delphi ...).

На языке, который использует try/ finally, код может выглядеть примерно так:

database.Open();
try {
    database.DoRiskyOperation();
} finally {
    database.Close();
}

Просто и понятно. Однако есть несколько недостатков:

• Если в языке нет детерминированных деструкторов, мне всегда приходится писать finallyблок, иначе я пропускаю ресурсы.
• Если DoRiskyOperationэто больше, чем один вызов метода - если у меня есть некоторая обработка в tryблоке - тогда Closeоперация может закончиться тем, что она будет немного дальше от Openоперации. Я не могу написать мою уборку прямо рядом с моим приобретением.
• Если у меня есть несколько ресурсов, которые необходимо получить, а затем освободить безопасным для исключений образом, я могу получить несколько уровней с блоками try/ finally.

Подход C ++ будет выглядеть так:

ScopedDatabaseConnection scoped_connection(database);
database.DoRiskyOperation();

Это полностью решает все недостатки finallyподхода. У него есть пара собственных недостатков, но они относительно незначительны:

• Есть хороший шанс, что вам нужно написать ScopedDatabaseConnectionкласс самостоятельно. Однако это очень простая реализация - всего 4 или 5 строк кода.
• Он включает в себя создание дополнительной локальной переменной, которой вы, очевидно, не являетесь поклонником, основываясь на вашем комментарии о «постоянном создании и уничтожении классов, которые полагаются на свои деструкторы для очистки вашего беспорядка, очень плохо» - но хороший компилятор оптимизирует любой дополнительной работы, связанной с дополнительной локальной переменной. Хороший дизайн C ++ во многом зависит от такого рода оптимизаций.

Лично, учитывая эти преимущества и недостатки, я считаю RAII гораздо более предпочтительным методом finally. Ваш пробег может варьироваться.

Наконец, поскольку RAII является такой устоявшейся идиомой в C ++, и для того, чтобы облегчить разработчикам часть бремени написания многочисленных Scoped...классов, существуют библиотеки, такие как ScopeGuard и Boost.ScopeExit, которые способствуют такой детерминированной очистке.

От Почему C ++ не предоставляет конструкцию "finally"? в FAQ по стилю и технике С ++ Бьярна Страуструпа :

Потому что C ++ поддерживает альтернативу, которая почти всегда лучше: техника «получение ресурсов - инициализация» (TC ++ PL3 раздел 14.4). Основная идея заключается в представлении ресурса локальным объектом, чтобы деструктор локального объекта освободил ресурс. Таким образом, программист не может забыть освободить ресурс.

Причина, по которой C ++ не имеет, finallyзаключается в том, что он не нужен в C ++. finallyиспользуется для выполнения некоторого кода независимо от того, произошло ли исключение или нет, что почти всегда является своего рода кодом очистки. В C ++ этот код очистки должен находиться в деструкторе соответствующего класса, и деструктор всегда будет вызываться, как finallyблок. Фраза использования деструктора для вашей очистки называется RAII .

В сообществе C ++ может быть больше разговоров о «безопасном от исключений» коде, но он почти одинаково важен в других языках, в которых есть исключения. Весь смысл «безопасного для исключений» кода состоит в том, что вы думаете о том, в каком состоянии ваш код остается, если исключение происходит в любой из функций / методов, которые вы вызываете.
В C ++ «безопасный для исключения» код немного важнее, потому что C ++ не имеет автоматической сборки мусора, которая заботится об объектах, оставшихся сиротами из-за исключения.

Причина, по которой безопасность исключений обсуждается более подробно в сообществе C ++, вероятно, также связана с тем фактом, что в C ++ вам нужно больше понимать, что может пойти не так, потому что в языке меньше сетей безопасности по умолчанию.

Другие обсуждали RAII как решение. Это совершенно хорошее решение. Но на самом деле это не решает, почему они не добавили, finallyтак как это очень популярная вещь. Ответ на этот вопрос является более фундаментальным для проектирования и разработки C ++: на протяжении всей разработки C ++ те, кто участвовал в этом, решительно сопротивлялись внедрению конструктивных особенностей, которые могут быть достигнуты с использованием других функций без особой суеты, и особенно там, где это требует введения. новых ключевых слов, которые могут сделать старый код несовместимым. Поскольку RAII предоставляет высокофункциональную альтернативу, finallyи вы finallyв любом случае можете использовать свой собственный язык в C ++ 11, это было мало чем нужно.

Все, что вам нужно сделать, это создать класс, Finallyкоторый вызывает функцию, переданную ее конструктору в его деструкторе. Тогда вы можете сделать это:

try
{
    Finally atEnd([&] () { database.close(); });

    database.doRisky();
}

Однако большинство нативных программистов на C ++ предпочитают чисто спроектированные объекты RAII.

Вы можете использовать шаблон «trap» - даже если вы не хотите использовать блок try / catch.

Поместите простой объект в требуемую область. В деструкторе этого объекта заложена ваша "финальная" логика. Независимо от того, что, когда стек размотан, будет вызван деструктор объекта, и вы получите свою конфету.

Ну, вы можете сделать что-то по-своему finally, используя Lambdas, который получит следующее для правильной компиляции (используя пример без RAII, конечно, не самый хороший кусок кода):

{
    FILE *file = fopen("test","w");

    finally close_the_file([&]{
        cout << "We're closing the file in a pseudo-finally clause." << endl;
        fclose(file);
    });
}

Смотрите эту статью .

Я не уверен, что согласен с утверждениями, что RAII является надмножеством finally. Ахиллесова пята RAII проста: исключения. RAII реализован с помощью деструкторов, и в C ++ всегда неправильно выбрасывать деструктор. Это означает, что вы не можете использовать RAII, когда вам нужен код очистки для выброса. С finallyдругой стороны, если бы они были реализованы, нет никаких оснований полагать, что было бы незаконно бросать из finallyблока.

Рассмотрим путь к коду:

void foo() {
    try {
        ... stuff ...
        complex_cleanup();
    } catch (A& a) {
        handle_a(a);
        complex_cleanup();
        throw;
    } catch (B& b) {
        handle_b(b);
        complex_cleanup();
        throw;
    } catch (...) {
        handle_generic();
        complex_cleanup();
        throw;
    }
}

Если бы мы имели, finallyмы могли бы написать:

void foo() {
    try {
        ... stuff ...
    } catch (A& a) {
        handle_a(a);
        throw;
    } catch (B& b) {
        handle_b(b);
        throw;
    } catch (...) {
        handle_generic();
        throw;
    } finally {
        complex_cleanup();
    }
}

Но я не могу найти способ получить эквивалентное поведение, используя RAII.

Если кто-то знает, как это сделать в C ++, я очень заинтересован в ответе. Я даже был бы счастлив с чем-то, на что полагалось, например, с обеспечением того, чтобы все исключения наследовались от одного класса с какими-то особыми возможностями или чем-то еще.