c++中有类似Java的吗
try {
...
}
catch (Throwable t) {
...
}
我试图调试Java/jni代码调用本机windows函数和虚拟机不断崩溃。本机代码在单元测试中表现良好,只有在通过jni调用时才会崩溃。一个通用的异常捕获机制将被证明是非常有用的。
c++中有类似Java的吗
try {
...
}
catch (Throwable t) {
...
}
我试图调试Java/jni代码调用本机windows函数和虚拟机不断崩溃。本机代码在单元测试中表现良好,只有在通过jni调用时才会崩溃。一个通用的异常捕获机制将被证明是非常有用的。
当前回答
try {
// ...
} catch (...) {
// ...
}
注意…catch里面是一个真正的省略号。三个点。
然而,由于c++异常不一定是基Exception类的子类,因此在使用此构造时无法实际看到抛出的异常变量。
其他回答
这是如何从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;
}
(在c++中)以可移植的方式捕获所有异常是不可能的。这是因为在c++上下文中,有些异常并不是异常。这包括除以零误差等。可以通过破解来获得在这些错误发生时抛出异常的能力,但这并不容易做到,当然也不容易以一种可移植的方式得到正确的处理。
如果你想捕获所有的STL异常,你可以这样做
try { ... } catch( const std::exception &e) { ... }
这将允许您使用e.what(),它将返回一个const char*,它可以告诉您有关异常本身的更多信息。这是与Java构造最相似的构造。
如果有人愚蠢地抛出一个不继承std::exception的异常,这将对您没有帮助。
try{
// ...
} catch (...) {
// ...
}
将捕获所有c++异常,但它应该被认为是糟糕的设计。你可以使用c++11新的current_exception机制,但是如果你没有能力使用c++11(遗留代码系统需要重写),那么你就没有命名异常指针来获取消息或名称。您可能希望为可以捕获的各种异常添加单独的catch子句,并且只捕获底部的所有内容以记录意外异常。例如:
try{
// ...
} catch (const std::exception& ex) {
// ...
} catch (const std::string& ex) {
// ...
} catch (...) {
// ...
}
简单来说,使用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(…)的正确方法。
对于无法正确调试使用JNI的程序的真正问题(或者在调试器下运行时不出现错误):
在这种情况下,在JNI调用(即所有本机方法都是私有的,类中的公共方法调用它们)周围添加Java包装器通常会有所帮助,这些包装器会做一些基本的完整性检查(检查所有“对象”都被释放,释放后“对象”没有被使用)或同步(将所有方法从一个DLL同步到单个对象实例)。让java包装器方法记录错误并抛出异常。
这通常有助于发现真正的错误(令人惊讶的是,这些错误主要出现在Java代码中,不遵守被调用函数的语义,导致一些讨厌的double-free或类似的情况),比尝试在本地调试器中调试大型并行Java程序更容易……
如果您知道原因,请将代码保存在可以避免该原因的包装器方法中。最好让你的包装器方法抛出异常,而不是你的JNI代码崩溃VM…