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

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

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

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

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

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

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

让我在这里提一下:Java

try 
{
...
}
catch (Exception e)
{
...
}

可能无法捕获所有异常!其实我以前也遇到过这种事，很让人抓狂;Exception派生自Throwable。因此，从字面上看，要捕获所有东西，你不希望捕获异常;你想抓住Throwable。

我知道这听起来很挑剔，但是当你花了好几天时间试图弄清楚“未捕获的异常”来自于被try包围的代码时……catch (Exception e)" block来自哪里，它会一直跟着你。

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

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

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

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

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

你可以使用

catch(...)

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

Can you run your JNI-using Java application from a console window (launch it from a java command line) to see if there is any report of what may have been detected before the JVM was crashed. When running directly as a Java window application, you may be missing messages that would appear if you ran from a console window instead. Secondly, can you stub your JNI DLL implementation to show that methods in your DLL are being entered from JNI, you are returning properly, etc? Just in case the problem is with an incorrect use of one of the JNI-interface methods from the C++ code, have you verified that some simple JNI examples compile and work with your setup? I'm thinking in particular of using the JNI-interface methods for converting parameters to native C++ formats and turning function results into Java types. It is useful to stub those to make sure that the data conversions are working and you are not going haywire in the COM-like calls into the JNI interface. There are other things to check, but it is hard to suggest any without knowing more about what your native Java methods are and what the JNI implementation of them is trying to do. It is not clear that catching an exception from the C++ code level is related to your problem. (You can use the JNI interface to rethrow the exception as a Java one, but it is not clear from what you provide that this is going to help.)