使用我所拥有的细节,我有理由确定您的问题归结为“Python 能否处理使用外部函数接口时发生的错误”。
我很确定答案是否定的,我整理了以下测试场景来解释原因:
这是我们的测试 C++ 模块(带有一些 C 用于名称修改),它将在我们面前爆炸test.cc
:
#include <iostream>
#include <signal.h>
class Test{
public:
void test(){
std::cout << "stackoverflow" << std::endl;
// this will crash us. shouldn't really matter what SIG as long as it crashes Python
raise (SIGABRT);
}
};
extern "C" {
Test* Test_new(){ return new Test(); }
void Test_example(Test* test){ test->test(); }
}
clang -shared -undefined dynamic_lookup -o test.so test.cc
还有我们的调用脚本test.py
:
from ctypes import cdll
test_so = cdll.LoadLibrary("test.so")
class PyTest:
def __init__(self):
self.obj = test_so.Test_new()
def output(self):
test_so.Test_example(self.obj)
if __name__ == "__main__":
p = PyTest()
p.output()
叫它:
Ξ /tmp/29_may → python test.py
stackoverflow
[1] 55992 abort python test.py
这会按预期使 Python 崩溃,并在 OS X 上生成一个很好的“报告错误”详细信息:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff95bf48ea __kill + 10
1 test.so 0x0000000110285006 Test::test() + 70
2 test.so 0x0000000110284fb5 Test_example + 21
3 _ctypes.so 0x000000011026d7c7 ffi_call_unix64 + 79
4 _ctypes.so 0x000000011026dfe6 ffi_call + 818
5 _ctypes.so 0x000000011026970b _ctypes_callproc + 867
6 _ctypes.so 0x0000000110263b91 PyCFuncPtr_call + 1100
7 org.python.python 0x000000010fd18ad7 PyObject_Call + 99
8 org.python.python 0x000000010fd94e7f PyEval_EvalFrameEx + 11417
9 org.python.python 0x000000010fd986d1 fast_function + 262
10 org.python.python 0x000000010fd95553 PyEval_EvalFrameEx + 13165
11 org.python.python 0x000000010fd91fb4 PyEval_EvalCodeEx + 1387
12 org.python.python 0x000000010fd91a43 PyEval_EvalCode + 54
13 org.python.python 0x000000010fdb1816 run_mod + 53
14 org.python.python 0x000000010fdb18b9 PyRun_FileExFlags + 133
15 org.python.python 0x000000010fdb13f9 PyRun_SimpleFileExFlags + 711
16 org.python.python 0x000000010fdc2e09 Py_Main + 3057
17 libdyld.dylib 0x00007fff926d15ad start + 1
我复制并粘贴了这个,因为它比 strace 更干净/更容易解析(另外,我很懒;)。呼叫__kill
是我们崩溃的地方;我们再也看不到 Python 的回归,这意味着它超出了我们的控制范围。
为了证明这一点,修改我们的test.py
intotest_handle_exception.py
以尝试捕获异常:
from ctypes import cdll
test_so = cdll.LoadLibrary("test.so")
class PyTest:
def __init__(self):
self.obj = test_so.Test_new()
def output(self):
test_so.Test_example(self.obj)
if __name__ == "__main__":
p = PyTest()
try:
p.output()
except:
print("If you're reading this, we survived somehow.")
并再次运行它:
Ξ /tmp/29_may → python test_handle_exception.py
stackoverflow
[1] 56297 abort python test_handle_exception.py
不幸的是,据我所知,我们无法在 Python 层捕获异常/崩溃,因为它发生在字节码控制“之下”。非特定Exception
子句将尝试捕获发生的任何异常,其中以下语句是捕获异常时采取的操作。If you're reading this, we survived somehow.
从未发送到标准输出,我们崩溃了,这意味着 Python 没有机会做出反应。
如果可以,请在 C++ 代码中处理此异常。您可能能够发挥创造力并使用多处理来分叉到一个可能会崩溃而不会关闭您的主进程的进程,但我对此表示怀疑。