c++ - 在堆上分配异常有什么陷阱吗？

Question

问题说明了一切:在堆上分配异常有什么陷阱吗？

我问是因为在堆上分配异常，结合 polymorphic exception idiom ，解决线程之间传输异常的问题(为了讨论方便，假设我不能使用exception_ptr)。或者至少我认为它确实...

我的一些想法:

• 异常处理程序必须捕获异常并知道如何删除它。这可以通过使用适当的删除器实际抛出 auto_ptr 来解决。
• 还有其他方法可以跨线程传输异常吗？

Answer 1

Are there any pitfalls with allocating exceptions on the heap?

一个明显的陷阱是堆分配可能会失败。

有趣的是，当异常被抛出时，它实际上抛出异常对象的拷贝，即throw 的参数。 .使用 gcc 时，it creates that copy in the heap但有一个转折。如果堆分配失败，它会使用静态紧急缓冲区而不是堆:

extern "C" void *
__cxxabiv1::__cxa_allocate_exception(std::size_t thrown_size) throw()
{
    void *ret;

    thrown_size += sizeof (__cxa_refcounted_exception);
    ret = malloc (thrown_size);

    if (! ret)
    {
        __gnu_cxx::__scoped_lock sentry(emergency_mutex);

        bitmask_type used = emergency_used;
        unsigned int which = 0;

        if (thrown_size > EMERGENCY_OBJ_SIZE)
            goto failed;
        while (used & 1)
        {
            used >>= 1;
            if (++which >= EMERGENCY_OBJ_COUNT)
                goto failed;
        }

        emergency_used |= (bitmask_type)1 << which;
        ret = &emergency_buffer[which][0];

    failed:;

        if (!ret)
            std::terminate ();
    }
}

因此，一种可能性是复制此功能以防止异常的堆分配失败。

The handler of the exception will have to catch the exception and know how to delete it. This can be solved by actually throwing an auto_ptr with the appropriate deleter.

不确定是否使用 auto_ptr<>是个好主意。这是因为复制 auto_ptr<>破坏原来的，所以在按值捕获之后，如 catch(std::auto_ptr<std::exception> e)随后throw;没有参数重新抛出原始异常可能会抛出 NULL auto_ptr<>因为它是从(我没试过)复制过来的。

出于这个原因，我可能会抛出一个简单的指针，比如 throw new my_exception(...)并按值手动捕获它 delete它。因为手动内存管理留下了内存泄漏的方法，所以我会创建一个小库来在线程之间传输异常，并将如此低级的代码放在那里，这样其余的代码就不必关心内存管理问题。

另一个问题是 throw 需要特殊的语法，比如 throw new exception(...) ，可能有点过于侵入，也就是说，可能存在无法更改的现有代码或第三方库，它们以标准方式抛出，如 throw exception(...) .坚持标准的 throw 语法并在顶级线程 catch block ，复制该异常并在另一个线程中重新抛出拷贝(可能在 join 上或在提取其他线程结果的函数中，尽管抛出的线程可能是独立的并且不会产生结果，但这完全是另一个问题，我们假设我们处理某种生命周期有限的工作线程)。这样，另一个线程中的异常处理程序可以通过引用或值以标准方式捕获异常，而无需处理堆。我可能会选择这条路。

您也可以看看 Boost: Transporting of Exceptions Between Threads .