C ++ 11中的范围（失败）？

Question

我写了一个非常简单的解决方案，但是有人笑了，发现了一个缺陷，如下所示http://ideone.com/IcWMEf

#include <iostream>
#include <ostream>
#include <functional>
#include <exception>
using namespace std;

// Wrong scope(failure)
class FailBlockT
{
    typedef function<void()> T;
    public:
    T t;
    FailBlockT(T t)
    {
        this->t=t;
    }
    ~FailBlockT()
    {
        if (std::uncaught_exception())
        {
            t();
        }
    }
};

struct Test
{
    ~Test()
    {
        try
        {
            FailBlockT f([]()
            {
                cout << "failure" << endl;
            });
            // there is no any exception here, but "failure" is printed.
            // See output below
        }
        catch(...)
        {
            cout << "some exception" << endl;
        }
    }
};

int main()
{
    try
    {
        Test t;
        throw 1;
    }
    catch(int){}
    return 0;
}

简而言之，问题是我的代码查看std::uncaught_exception()。当抛出异常并执行正常的析构函数时。如果我在那里使用范围故障，它会查看 std::uncaught_exception() 并认为对象范围由于异常而丢失，而不是简单地走出范围。

我想不出任何好的解决方案来区分正常离开范围与在其中抛出异常。是的，我知道在 dtors 中抛出是一个坏主意，但这就是为什么我没有注意到这个问题，因为我从不抛出异常。

我如何区分/解决这个问题？

Answer 1

我想不出任何好的解决方案来区分正常离开范围与在其中抛出异常。

检查stack_unwinding library - 我已经在 C++ 中实现了范围（失败）和范围（成功）功能。

它基于平台特定的函数 uncaught_exception_count。它类似于标准库中的 std::uncaught_exception，但它不是返回布尔结果，而是返回 unsigned int 显示当前未捕获异常的计数。

目前它在 {Clang 3.2, GCC 3.4.6, GCC 4.1.2, GCC 4.4.6, GCC 4.4.7, MSVC2005SP1, MSVC2008SP1, MSVC2010SP1, MSVC2012} x {x32, x64} 上进行测试。

在 C++11 中，以下语法是 available:

try
{
    int some_var=1;
    cout << "Case #1: stack unwinding" << endl;
    scope(exit)
    {
        cout << "exit " << some_var << endl;
        ++some_var;
    };
    scope(failure)
    {
        cout << "failure " << some_var << endl;
        ++some_var;
    };
    scope(success)
    {
        cout << "success " << some_var << endl;
        ++some_var;
    };
    throw 1;
} catch(int){}
{
    int some_var=1;
    cout << "Case #2: normal exit" << endl;
    scope(exit)
    {
        cout << "exit " << some_var << endl;
        ++some_var;
    };
    scope(failure)
    {
        cout << "failure " << some_var << endl;
        ++some_var;
    };
    scope(success)
    {
        cout << "success " << some_var << endl;
        ++some_var;
    };
}

在 C++98 中更多的是noisier:

try
{
    cout << "Case #1: stack unwinding" << endl;
    BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END
    SCOPE_FAILURE(void) { cout << "failure" << endl; } SCOPE_FAILURE_END
    SCOPE_SUCCESS(void) { cout << "success" << endl; } SCOPE_SUCCESS_END
    throw 1;
} catch(int){}
{
    cout << "Case #2: normal exit" << endl;
    BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END
    SCOPE_FAILURE(void) { cout << "failure" << endl; } SCOPE_FAILURE_END
    SCOPE_SUCCESS(void) { cout << "success" << endl; } SCOPE_SUCCESS_END
}

此外，库具有UNWINDING_AWARE_DESTRUCTOR 功能。 Example:

struct DestructorInClass
{
    UNWINDING_AWARE_DESTRUCTOR(DestructorInClass,unwinding)
    {
        cout << "DestructorInClass, unwinding: "
             << ( unwinding ? "true" : "false" ) << endl;
    }
};

但是，在某些情况下，UNWINDING_AWARE_DESTRUCTOR 可能会give wrong results（尽管范围（成功）和范围（失败）功能不受此类问题的影响）。

Answer 2

没有抛出异常，但它认为有。

抛出了一个异常，只是不是从那里。

C++11 中没有机制可以询问“是否从我下面的代码中抛出了异常，但 不是 来自调用堆栈中其他地方的代码？” std::uncaught_exception 正在做它应该做的事情：说明在调用函数时当前是否存在正在解决的异常。有，所以它返回true。

C++17 增加了std::uncaught_exceptions（注意复数），可以用来检测差异。使用这样的工具，您可以使您的 FailBlock 对象工作：

template<typename Func>
class FailBlockT
{
private:
    int e_count_;
    T t_;

public:
    FailBlockT(T t) : e_count_(std::uncaught_exceptions()), t_(t) {}

    FailBlock(const FailBlock &) = delete; //The type should not be mobile.

    ~FailBlockT()
    {
        if (std::uncaught_exceptions() != e_count_)
        {
            t_();
        }
    }
};

std::uncaught_exceptions() 返回调用时引发堆栈展开的异常数。如果在对象的构造函数和析构函数期间编号相同（假设它是堆栈对象），则由于使用此类型的位置抛出异常，因此不会调用析构函数。

但是，如果没有这个工具，您就无法区分引发范围退出的异常而不是在恰好发生异常展开时退出范围。因此，您将不得不像其他人一样硬着头皮捕捉异常。

或者只是不要把这个FailBlock 东西放在析构函数中。在我看来，那些应该直接进入可以实际抛出的常规函数​​（而析构函数永远不应该抛出）。在我看来，您担心的是一个没有任何实际意义的极端案例。