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

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

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.

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

Daniel Marinescu