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

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

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

至少我是这么想的。

这是如何从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;
}

可以这样写:

try
{
  //.......
}
catch(...) // <<- catch all
{
  //.......
}

但是这里有一个非常不明显的风险:您无法找到try块中抛出的错误的确切类型，因此当您确定无论异常类型是什么，程序都必须以catch块中定义的方式持续存在时，可以使用这种catch。

你可以使用

catch(...)

但这是非常危险的。在约翰·罗宾斯的《调试Windows》一书中，他讲述了一个战争故事，一个非常严重的bug被一个catch(…)命令掩盖了。您最好捕获特定的异常。捕获您认为try块可能合理抛出的任何异常，但如果确实发生意外，则让代码抛出更高的异常。

简单来说，使用catch(…)。但是，请注意catch(…)是与throw结合使用的;基本上:

try{
    foo = new Foo;
    bar = new Bar;
}
catch(...)       // will catch all possible errors thrown. 
{ 
    delete foo;
    delete bar;
    throw;       // throw the same error again to be handled somewhere else
}

这是使用catch(…)的正确方法。

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

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