你可以使用

catch(...)

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

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

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

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

至少我是这么想的。

如果你正在寻找特定于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++异常，还可以捕获访问违规或其他系统异常。

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

将捕获所有c++异常，但它应该被认为是糟糕的设计。你可以使用c++11新的current_exception机制，但是如果你没有能力使用c++11(遗留代码系统需要重写)，那么你就没有命名异常指针来获取消息或名称。您可能希望为可以捕获的各种异常添加单独的catch子句，并且只捕获底部的所有内容以记录意外异常。例如:

try{
    // ...
} catch (const std::exception& ex) {
    // ...
} catch (const std::string& ex) {
    // ...
} catch (...) {
    // ...
}

通用的异常捕获机制 会非常有用。

表示怀疑。你已经知道你的代码坏了，因为它崩溃了。进食异常可能会掩盖这一点，但这可能只会导致更糟糕、更微妙的错误。

你真正需要的是一个调试器……

对于无法正确调试使用JNI的程序的真正问题(或者在调试器下运行时不出现错误):

在这种情况下，在JNI调用(即所有本机方法都是私有的，类中的公共方法调用它们)周围添加Java包装器通常会有所帮助，这些包装器会做一些基本的完整性检查(检查所有“对象”都被释放，释放后“对象”没有被使用)或同步(将所有方法从一个DLL同步到单个对象实例)。让java包装器方法记录错误并抛出异常。

这通常有助于发现真正的错误(令人惊讶的是，这些错误主要出现在Java代码中，不遵守被调用函数的语义，导致一些讨厌的double-free或类似的情况)，比尝试在本地调试器中调试大型并行Java程序更容易……

如果您知道原因，请将代码保存在可以避免该原因的包装器方法中。最好让你的包装器方法抛出异常，而不是你的JNI代码崩溃VM…