这是如何从catch(…)中反向工程异常类型，如果你需要(可能有用时，从第三方库捕获未知)使用GCC:

#include <iostream>

#include <exception>
#include <typeinfo>
#include <stdexcept>

int main()
{
    try {
        throw ...; // throw something
    }
    catch(...)
    {
        std::exception_ptr p = std::current_exception();
        std::clog <<(p ? p.__cxa_exception_type()->name() : "null") << std::endl;
    }
    return 1;
}

如果你有能力使用Boost，你可以让你的捕捉部分更简单(在外部)，并具有跨平台的潜力

catch (...)
{
    std::clog << boost::current_exception_diagnostic_information() << std::endl;
}

如果你正在寻找特定于windows的解决方案，那么有结构化异常处理: https://learn.microsoft.com/en-us/cpp/cpp/try-except-statement

代码如下所示

__try
{
   // code here may throw or make access violation
}
__except( EXCEPTION_EXECUTE_HANDLER )
{
    // after exception code here, e.g. log the error
}

它不仅可以捕获c++异常，还可以捕获访问违规或其他系统异常。

这取决于编译器环境。 GCC不捕获这些。 Visual Studio和我之前用的Borland。

因此，关于崩溃的结论是，它取决于开发环境的质量。

c++ 规范说catch(…)必须捕获任何异常，但它不是在所有情况下都捕获。

至少我是这么想的。

有人应该补充说，在c++代码中无法捕捉“崩溃”。它们不会抛出异常，而是做任何它们喜欢做的事情。当你看到一个程序因为空指针的解引用而崩溃时，它正在做未定义的行为。没有std::null_pointer_exception。试图捕捉异常在那里没有帮助。

只是为了以防万一，有人正在阅读这篇文章，并认为他可以得到程序崩溃的原因。应该使用像gdb这样的调试器。

try {
   // ...
} catch (...) {
   // ...
}

注意…catch里面是一个真正的省略号。三个点。

然而，由于c++异常不一定是基Exception类的子类，因此在使用此构造时无法实际看到抛出的异常变量。

(在c++中)以可移植的方式捕获所有异常是不可能的。这是因为在c++上下文中，有些异常并不是异常。这包括除以零误差等。可以通过破解来获得在这些错误发生时抛出异常的能力，但这并不容易做到，当然也不容易以一种可移植的方式得到正确的处理。

如果你想捕获所有的STL异常，你可以这样做

try { ... } catch( const std::exception &e) { ... }

这将允许您使用e.what()，它将返回一个const char*，它可以告诉您有关异常本身的更多信息。这是与Java构造最相似的构造。

如果有人愚蠢地抛出一个不继承std::exception的异常，这将对您没有帮助。