Поддерживает ли C ++ блоки «finally»? (И что это за RAII, о котором я все время слышу?)

Это означает, что когда вы достигаете нирваны RAII и все члены класса используют RAII (например, интеллектуальные указатели), вы можете обойтись очень простым (возможно, даже по умолчанию) dtor для класса-владельца, поскольку ему не нужно вручную управлять своим время жизни членского ресурса.

почему даже управляемые языки предоставляют finally-блок, несмотря на то, что ресурсы в любом случае автоматически освобождаются сборщиком мусора?

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

Что касается динамически распределяемых данных, многие утверждают, что вам следует использовать интеллектуальные указатели.

Тем не мение...

RAII переносит ответственность за безопасность исключений с пользователя объекта на дизайнера.

К сожалению, это его собственная ошибка. От старых привычек программирования на C трудно избавиться. Когда вы используете библиотеку, написанную на C или очень в стиле C, RAII использоваться не будет. Если не считать переписывания всего интерфейса API, это как раз то, с чем вам придется работать. Тогда отсутствие «наконец-то» действительно кусает.

Еще одна эмуляция блока "finally" с использованием лямбда-функций C ++ 11

Будем надеяться, что компилятор оптимизирует приведенный выше код.

template <typename TCode, typename TFinallyCode>
inline void with_finally(const TCode &code, const TFinallyCode &finally_code)
{
    try
    {
        code();
    }
    catch (...)
    {
        try
        {
            finally_code();
        }
        catch (...) // Maybe stupid check that finally_code mustn't throw.
        {
            std::terminate();
        }
        throw;
    }
    finally_code();
}

Теперь мы можем написать такой код:

При желании вы можете заключить эту идиому в макрос «попробуйте - наконец»:

with_finally(
    [&]()
    {
        try
        {
            // Doing some stuff that may throw an exception
        }
        catch (const exception1 &)
        {
            // Handling first class of exceptions
        }
        catch (const exception2 &)
        {
            // Handling another class of exceptions
        }
        // Some classes of exceptions can be still unhandled
    },
    [&]() // finally
    {
        // This code will be executed in all three cases:
        //   1) exception was not thrown at all
        //   2) exception was handled by one of the "catch" blocks above
        //   3) exception was not handled by any of the "catch" block above
    }
);

Теперь в C ++ 11 доступен блок «finally»:

// Please never throw exception below. It is needed to avoid a compilation error
// in the case when we use "begin_try ... finally" without any "catch" block.
class never_thrown_exception {};

#define begin_try    with_finally([&](){ try
#define finally      catch(never_thrown_exception){throw;} },[&]()
#define end_try      ) // sorry for "pascalish" style :(

Лично мне не нравится «макро» версия идиомы «finally», и я бы предпочел использовать чистую функцию «with_finally», хотя синтаксис в этом случае более громоздкий.

begin_try
{
    // A code that may throw
}
catch (const some_exception &)
{
    // Handling some exceptions
}
finally
{
    // A code that is always executed
}
end_try; // Sorry again for this ugly thing

Вы можете протестировать приведенный выше код здесь: http://coliru.stacked-crooked.com/a/1d88f64cb27b3813

PS

Если вам нужен блок finally в коде, тогда охрана с ограниченным объемом или ON_FINALLY/ON_EXCEPTION, вероятно, лучше подойдут для ваших нужд.

Вот краткий пример использования ON_FINALLY / ON_EXCEPTION:

Извините, что откопал такую ​​старую ветку, но есть серьезная ошибка в следующих рассуждениях:

void function(std::vector<const char*> &vector)
{
    int *arr1 = (int*)malloc(800*sizeof(int));
    if (!arr1) { throw "cannot malloc arr1"; }
    ON_FINALLY({ free(arr1); });

    int *arr2 = (int*)malloc(900*sizeof(int));
    if (!arr2) { throw "cannot malloc arr2"; }
    ON_FINALLY({ free(arr2); });

    vector.push_back("good");
    ON_EXCEPTION({ vector.pop_back(); });

    ...

RAII переносит ответственность за безопасность исключений с пользователя объекта на проектировщика (и разработчика) объекта. Я бы сказал, что это правильное место, поскольку тогда вам нужно только один раз получить правильную безопасность исключений (в дизайне / реализации). Используя finally, вам нужно обеспечить правильную безопасность исключений каждый раз, когда вы используете объект.

Чаще всего вам приходится иметь дело с динамически выделяемыми объектами, динамическим числом объектов и т. Д. В блоке try некоторый код может создать много объектов (сколько определяется во время выполнения) и сохранить указатели на них в списке. Это не экзотический сценарий, а очень распространенный. В этом случае вам нужно написать что-нибудь вроде

Конечно, сам список будет уничтожен при выходе из области видимости, но это не очистит созданные вами временные объекты.

void DoStuff(vector<string> input)
{
  list<Foo*> myList;

  try
  {    
    for (int i = 0; i < input.size(); ++i)
    {
      Foo* tmp = new Foo(input[i]);
      if (!tmp)
        throw;

      myList.push_back(tmp);
    }

    DoSomeStuff(myList);
  }
  finally
  {
    while (!myList.empty())
    {
      delete myList.back();
      myList.pop_back();
    }
  }
}

Вместо этого вы должны пойти по уродливому маршруту:

Также: почему даже управляемые языки предоставляют finally-блок, несмотря на то, что ресурсы в любом случае автоматически освобождаются сборщиком мусора?

void DoStuff(vector<string> input)
{
  list<Foo*> myList;

  try
  {    
    for (int i = 0; i < input.size(); ++i)
    {
      Foo* tmp = new Foo(input[i]);
      if (!tmp)
        throw;

      myList.push_back(tmp);
    }

    DoSomeStuff(myList);
  }
  catch(...)
  {
  }

  while (!myList.empty())
  {
    delete myList.back();
    myList.pop_back();
  }
}

Подсказка: с помощью «finally» вы можете сделать больше, чем просто освобождение памяти.

FWIW, Microsoft Visual C ++, наконец, поддерживает try, и исторически он использовался в приложениях MFC как метод перехвата серьезных исключений, которые в противном случае привели бы к сбою. Например;

Я использовал это в прошлом, чтобы делать такие вещи, как сохранение резервных копий открытых файлов перед выходом. Однако некоторые настройки отладки JIT нарушают этот механизм.

int CMyApp::Run() 
{
    __try
    {
        int i = CWinApp::Run();
        m_Exitok = MAGIC_EXIT_NO;
        return i;
    }
    __finally
    {
        if (m_Exitok != MAGIC_EXIT_NO)
            FaultHandler();
    }
}

Как указано в других ответах, C ++ может поддерживать

int CMyApp::Run() 
{
    __try
    {
        int i = CWinApp::Run();
        m_Exitok = MAGIC_EXIT_NO;
        return i;
    }
    __finally
    {
        if (m_Exitok != MAGIC_EXIT_NO)
            FaultHandler();
    }
}

Таким образом, C ++ не только поддерживает finally, но и рекомендуется использовать его во многих распространенных сценариях использования.

Пример использования реализации GSL будет выглядеть так:

Реализация и использование GSL очень похожи на те, что описаны в ответе Паоло Болзони. Одно отличие состоит в том, что объект, созданный gsl::finally(), не имеет вызова disable(). Если вам нужна эта функциональность (скажем, чтобы вернуть ресурс после его сборки и никаких исключений не должно произойти), вы можете предпочесть реализацию Паоло. В противном случае использование GSL максимально приближено к использованию стандартных функций.

#include <gsl/gsl_util.h>

void example()
{
    int handle = get_some_resource();
    auto handle_clean = gsl::finally([&handle] { clean_that_resource(handle); });

    // Do a lot of stuff, return early and throw exceptions.
    // clean_that_resource will always get called.
}

У меня есть случай использования, когда я думаю, что finally должен быть вполне приемлемой частью языка C ++ 11, поскольку я думаю, что его легче читать с точки зрения потока. Мой вариант использования - это цепочка потоков потребитель / производитель, где в конце выполнения отправляется дозорный finally, чтобы закрыть все потоки.

Если бы C ++ поддерживал это, вы бы хотели, чтобы ваш код выглядел так:

Я думаю, что это более логично, чем помещать ваше объявление finally в начале цикла, поскольку оно происходит после выхода из цикла ... но это принятие желаемого за действительное, потому что мы не можем сделать это на C ++. Обратите внимание на то, что очередь downstream подключена к другому потоку, поэтому вы не можете поместить дозор push(nullptr) в деструктор downstream, потому что он не может быть уничтожен в этот момент ... он должен оставаться в живых, пока другой поток не получит nullptr.

    extern Queue downstream, upstream;

    int Example()
    {
        try
        {
           while(!ExitRequested())
           {
             X* x = upstream.pop();
             if (!x) break;
             x->doSomething();
             downstream.push(x);
           } 
        }
        finally { 
            downstream.push(nullptr);
        }
    }

Итак, вот как использовать класс RAII с лямбдой, чтобы сделать то же самое:

и вот как вы его используете:

    class Finally
    {
    public:

        Finally(std::function<void(void)> callback) : callback_(callback)
        {
        }
        ~Finally()
        {
            callback_();
        }
        std::function<void(void)> callback_;
    };

Не совсем, но вы можете в некоторой степени имитировать, например:

    extern Queue downstream, upstream;

    int Example()
    {
        Finally atEnd([](){ 
           downstream.push(nullptr);
        });
        while(!ExitRequested())
        {
           X* x = upstream.pop();
           if (!x) break;
           x->doSomething();
           downstream.push(x);
        }
    }

Обратите внимание, что блок finally может сам вызвать исключение до того, как исходное исключение будет создано повторно, тем самым отбросив исходное исключение. Это то же самое поведение, что и в конечном блоке Java. Кроме того, вы не можете использовать return внутри блоков try & catch.

int * array = new int[10000000];
try {
  // Some code that can throw exceptions
  // ...
  throw std::exception();
  // ...
} catch (...) {
  // The finally-block (if an exception is thrown)
  delete[] array;
  // re-throw the exception.
  throw; 
}
// The finally-block (if no exception was thrown)
delete[] array;

Я придумал макрос

int * array = new int[10000000];
try {
  // Some code that can throw exceptions
  // ...
  throw std::exception();
  // ...
} catch (...) {
  // The finally-block (if an exception is thrown)
  delete[] array;
  // re-throw the exception.
  throw; 
}
// The finally-block (if no exception was thrown)
delete[] array;

ПРЕДУПРЕЖДЕНИЕ: в более ранней версии этого ответа использовалась другая реализация концепции со многими другими ограничениями.

Сначала давайте определим вспомогательный класс.

Тогда есть собственно макрос.

#include <future>

template <typename Fun>
class FinallyHelper {
    template <typename T> struct TypeWrapper {};
    using Return = typename std::result_of<Fun()>::type;

public:    
    FinallyHelper(Fun body) {
        try {
            execute(TypeWrapper<Return>(), body);
        }
        catch(...) {
            m_promise.set_exception(std::current_exception());
        }
    }

    Return get() {
        return m_promise.get_future().get();
    }

private:
    template <typename T>
    void execute(T, Fun body) {
        m_promise.set_value(body());
    }

    void execute(TypeWrapper<void>, Fun body) {
        body();
    }

    std::promise<Return> m_promise;
};

template <typename Fun>
FinallyHelper<Fun> make_finally_helper(Fun body) {
    return FinallyHelper<Fun>(body);
}

Его можно использовать так:

#define try_with_finally for(auto __finally_helper = make_finally_helper([&] { try 
#define finally });                         \
        true;                               \
        ({return __finally_helper.get();})) \
/***/

Использование std::promise делает его очень простым в реализации, но, вероятно, также вносит немало ненужных накладных расходов, которых можно было бы избежать, повторно реализовав только необходимые функции из std::promise.

void test() {
    try_with_finally {
        raise_exception();
    }    

    catch(const my_exception1&) {
        /*...*/
    }

    catch(const my_exception2&) {
        /*...*/
    }

    finally {
        clean_it_all_up();
    }    
}

¹ ПРЕДОСТЕРЕЖЕНИЕ: есть несколько вещей, которые работают не так, как java-версия finally. С верхней части моей головы:

В общем, я не знаю, буду ли я когда-нибудь использовать эту штуку сам, но с ней было весело играть. :)

1. после try должен быть хотя бы один catch() блок: это требование C ++;
2. если функция имеет возвращаемое значение, отличное от void, но нет возврата в блоках try и catch()'s, компиляция завершится неудачно, потому что макрос finally расширится до кода, который захочет вернуть void. Это могло быть, ошибочно, недействительным из-за наличия макроса finally_noreturn.
3. Как заявляли многие люди, решение состоит в том, чтобы использовать функции C ++ 11, чтобы избежать блоков finally. Одна из функций - finally.

невозможно выйти из внешнего цикла с помощью оператора break из блоков try и catch(), поскольку они находятся внутри лямбда-функции;

Вот ответ Мефана, написанный с использованием шаблонов RAII.

Еще одно введение в использование unique_ptr с контейнерами стандартной библиотеки C ++: здесь

#include <vector>
#include <memory>
#include <list>
using namespace std;

class Foo
{
 ...
};

void DoStuff(vector<string> input)
{
    list<unique_ptr<Foo> > myList;

    for (int i = 0; i < input.size(); ++i)
    {
      myList.push_back(unique_ptr<Foo>(new Foo(input[i])));
    }

    DoSomeStuff(myList);
}

Я также считаю, что RIIA не является полностью полезной заменой обработки исключений и наличия файла finally. Кстати, я также считаю, что RIIA - плохая репутация. Я называю эти классы «дворниками» и использую их МНОГОЧИСЛЕННО. В 95% случаев они не инициализируют и не собирают ресурсы, они вносят какие-то изменения в определенную область действия или берут что-то уже настроенное и проверяют, что это уничтожено. Это официальное имя шаблона, одержимого Интернетом, меня ругают за то, что я даже предполагаю, что мое имя может быть лучше.

Я просто не думаю, что разумно требовать, чтобы при каждой сложной настройке какого-то специального списка вещей был написан класс, содержащий его, чтобы избежать осложнений при очистке всего этого резервного копирования перед лицом необходимости поймать несколько типы исключений, если что-то пойдет не так в процессе. Это привело бы к появлению множества специальных классов, которые в противном случае просто не понадобились бы.

Да, это нормально для классов, которые предназначены для управления конкретным ресурсом, или для общих классов, которые предназначены для обработки набора аналогичных ресурсов. Но даже если у всех задействованных вещей есть такие оболочки, координация очистки может быть не просто вызовом деструкторов в обратном порядке.

Я думаю, что для C ++ имеет смысл иметь наконец. Я имею в виду, черт возьми, за последние десятилетия на него было приклеено так много мелочей и бобов, что кажется, что странные люди внезапно станут консервативными по сравнению с чем-то вроде finally, которое может быть весьма полезным и, вероятно, не таким сложным, как некоторые другие вещи, которые были добавил (хотя это всего лишь предположение с моей стороны.)

ИЗМЕНЕНО

Если вы не прерываете / продолжаете / не возвращаетесь и т. д., вы можете просто добавить уловку к любому неизвестному исключению и поместить за ним код Always. Это также происходит, когда вам не нужно генерировать исключение повторно.

Обычно, наконец, на других языках программирования обычно выполняется независимо от того, что (обычно означает независимо от любого возврата, прерывания, продолжения, ...) за исключением какой-то системы exit(), которая сильно отличается в зависимости от языка программирования - например, PHP и Java просто завершают работу в этот момент, но Python все равно выполняется, а затем завершается.

try{
   // something that might throw exception
} catch( ... ){
   // what to do with uknown exception
}

//final code to be called always,
//don't forget that it might throw some exception too
doSomeCleanUp(); 

Также смотрите ответы в: stackoverflow.com/questions/7779652/

Но код, который я описал выше, не работает таким образом
= ›следующий код выводит ТОЛЬКО something wrong!:

Так в чем проблема?

#include <stdio.h>
#include <iostream>
#include <string>

std::string test() {
    try{
       // something that might throw exception
       throw "exceptiooon!";

       return "fine";
    } catch( ... ){
       return "something wrong!";
    }
    
    return "finally";
}

int main(void) {
    
    std::cout << test();
    
    
    return 0;
}