{
   File a,b;
   // ...
   b.close(); // may throw
   a.close(); // may throw
}

{
   File a,b;
   // ...
}

{
    cout << "Case #1: stack unwinding" << endl;
    scope_action exit=make<scope_exit>(Print(" exit"));
    scope_action failure=make<scope_failure>(Print(" failure")); 
    scope_action success=make<scope_success>(Print(" success"));
    throw 1;
}

Boost.ScopeExit is similar to scope(exit) feature built into the D programming language.

A curious reader may notice that the library does not implement scope(success) and scope(failure) of the D language.
Unfortunately, these are not possible in C++ because failure or success conditions cannot be determined by calling std::uncaught_exception (see Guru of the Week #47 for details about std::uncaught_exception and if it has any good use at all).
However, this is not a big problem because these two D's constructs can be expressed in terms of scope(exit) and a bool commit variable (similarly to some examples presented in the Tutorial section).

15.5.3 The std::uncaught_exceptions() function [except.uncaught]
1 An exception is considered uncaught after completing the initialization of the exception object (15.1) until completing the activation of a handler for the exception (15.3). This includes stack unwinding. If the exception is rethrown (15.1), it is considered uncaught from the point of rethrow until the rethrown exception is caught again. The function std::uncaught_exceptions() (18.8.4) returns the number of uncaught exceptions.

Added SCOPE_FAIL and SCOPE_SUCCESS macros in non-portable C++.

Summary:
Added SCOPE_FAIL and SCOPE_SUCCESS macros in non-portable C++. The macros are similar to D's scope(failure) and scope(success).
Currently the supported platforms are GCC and MSVC. For all others, std::uncaught_exception() is used, which will fail if the macros are used in a destructor called during stack unwinding.
@override-unit-failures

Test Plan:
1. Added new unit test to ScopeGuardTest.cpp.
2. Ran fbconfig -r folly && fbmake dbg
3. Ran _build/dbg/folly/test/scope_guard_test to make sure my unit test was running and passing.

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1033621

try {
    writeDocument();
catch( exception& e ) {
    // обработчик
}

class A {... ~A() { ... throw ... } };
void foo() {
    A a;
}

void bar() {
   try {
     foo();
   } catch(...) {
       // И ЧТО?
   }
}

На данный момент, библиотека реализована поверх платформо-зависимой реализации функции uncaught_exception_count.
uncaught_exception_count — это функция подобная std::uncaught_exception из стандартной библиотеки, но вместо булевского результата возвращает unsigned int, показывающий текущее количество uncaught exceptions

#include <iostream>
#include <exception>
using namespace std;
 
struct T
{
    ~T()
    {
        cout << "~T()";
        throw 1;
    }
};
 
int main()
{
    try
    {
        T t[10];
    }
    catch(int)
    {
        cout << "catch";
    }
    return 0;
}

class RAII_Deffered
{
    bool fail_on_flush;
public:
    // Normal contrustor
    RAII_Deffered(bool fail_on_flush_) : fail_on_flush(fail_on_flush_)
    {
        cout << "acquiring resource" << endl;
    }
    // Release part of destructor.
    // Herb Sutter: "letting go of a resource" must never fail
    // (http://cpp-next.com/archive/2012/08/evil-or-just-misunderstood/)
    TWO_STAGE_DESTRUCTOR_RELEASE(RAII_Deffered)
    {
        cout << "release resource" << endl;
    }
    // Deferred part of destructor. May fail(for instance fflush).
    // Called when object is destroyed due to normal flow, not stack unwinding
    TWO_STAGE_DESTRUCTOR_DEFERRED(RAII_Deffered)
    {
        cout << "flush pending actions on resource" << endl;
        if(fail_on_flush) throw 1;
    }
};

~Foo(bool due_to_unwinding)
{
    try
    {
        if(!due_to_unwinding) deferred_part_of_destructor();
    }
    catch(...)
    {
        release_part_of_destructor();
        throw;
    }
    release_part_of_destructor();
}

void fsome(/* ... */)
{
    OutFile a("a"),b("b");
    a.write("Hello");
    b.write("World");
    // ...
    b.flush(); // Fail #1
    a.flush(); // Fail #2
}

void fsome(/* ... */)
{
    OutFile a("a"),b("b");
    a.write("Hello");
    b.write("World");
    // ...
    // b.~OutFile():
    //     1. flush - Fail #1, throw exception
    //     2. fclose - called anyway
    // a.~OutFile() - called due to stack unwinding:
    //     1. flush is not called, due to stack unwinding
    //     2. fclose - called anyway
}

EP>>То же самое, что и при обычных исключениях

EP>>void fsome(/* ... */)
EP>>{
EP>>    OutFile a("a"),b("b");
EP>>    a.write("Hello");
EP>>    b.write("World");
EP>>    // ...
EP>>    b.flush(); // Fail #1
EP>>    a.flush(); // Fail #2
EP>>}
EP>>

V>В нигде. Будет как отдельный метод. Из деструктора звать fflush не буду, только fclose.

V>Мое бескомпромиссное имхо — кидать из деструкторов пытаются те, кто не умеет их готовить.

{
    Something a,b;
    // ...
    b.deferred(); // may throw
    a.deferred(); // may throw
}

{
    Something a,b;
    // ...
}

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

Их обработка обычно происходит несколькими уровнями выше, чем непосредственно код в котором они произошли, и все объекты тоже уже удаленны. Хотя бы потому, что во многих случаях в том месте где они произошли — недостаточно информации для их обработки/исправления. Это одна из главных фич исключений.
Использовать исключения, для кода, в котором каждый вызов функции обвёрнут в try/catch — глупо, уж лучше коды возврата (или что ты хотел показать свои примером?).

EP>>Как это относится к кидающим/не кидающим деструкторам? Эта ситуация может случится и без них

{
    Something a,b;
    // ...
    b.deferred(); // may throw
    a.deferred(); // may throw
}

AS>Как ни странно, но мой опыт говорит, что при работе с объектом уровня File исключение не должно произойти нигде

1. Освобождение ресурсов не должно фейлится (“letting go of a resource” must never fail Herb Sutter http://cpp-next.com/archive/2012/08/evil-or-just-misunderstood/)
2. Освобождение ресурсов должно произойти в любом случае — утечек быть не должно
3. Поддержка отложенных действий (flush) — желательна. Такие действия могут фэйлится
4. Если отложенное действие фэйлится — пользователь должен узнать об этом. Проглатывание исключений (потеря информации) — не является хорошим решением.

AS>классическую проблему — что делать, если при выкидывании исключения в деструкторе еще исключение

int main(int,char *[])
{
    try
    {
        cout << "Case #1: stack unwinding" << endl;
        BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END
        BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END
        BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END
        throw 1;
    } catch(int){}
    {
        cout << "Case #2: normal exit" << endl;
        BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END
        BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END
        BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END
    }
    return 0;
}

ExpectedStdoutTest test_cout
(
        "Case #1: stack unwinding\n"
        "failure\n"
        "exit\n"
        "Case #2: normal exit\n"
        "success\n"
        "exit\n"
);

EP>>{
EP>>    Something a,b;
EP>>    // ...
EP>>    b.deferred(); // may throw
EP>>    a.deferred(); // may throw
EP>>}
EP>>

EP>>{
EP>>    Something a,b;
EP>>    // ...
EP>>}
EP>>

E>Потому, что это намного менее очевидно для программиста поддерживающего код...

{
    Something a,b;
    BOOST_SCOPE_SUCCESS(void) { b.deferred(); // may throw } BOOST_SCOPE_SUCCESS_END
    BOOST_SCOPE_SUCCESS(void) { a.deferred(); // may throw } BOOST_SCOPE_SUCCESS_END
    // ...
}

E>>Что-нибудь потрёшь?..

void f()
{
    File a("some");
    try
    {
        a.write("...");
    }
    catch(/*something*/)
    {
        /*do something*/
    }
    // ...
    try
    {
        a.flush()
    }
    catch(/*something*/)
    {
        // do something
    }
}

void f()
{
    File a("some");
    a.write("...");
    // ...
    a.flush()
}

I have serious problems with your suggestion that re-try-ability is fundamental to what can or should report an error, but leaving that argument aside for the time being, consider this: the exception can always carry any information needed to re-try these side-effects.
...
I’ll say the same thing to you that I said to Herb: the ability to usefully re-try an operation has no obvious bearing on whether it’s a good idea to report that the operation failed. In fact, I’ll go further: if the best response to a particular problem is likely to be “try that again,” an exception is probably not the most appropriate way to report the situation, because it’ll usually need to be re-tried very close to the place where it occurred.
...
Here’s another way of looking at it: destructors are the only way we have in C++ of attaching side-effects to block exit (c.f. finally in other languages), and, yes, to the destruction of other objects, neither one of which is inherently a bad thing to do. Side-effects can fail to complete, and when they do, there are reasons to want to know about it.

Daniel Marinescu