C++异常处理与模块间传递技巧

在C++跨模块调用中，必须在接口层通过try-catch阻止异常穿透边界，将C++异常转换为错误码或错误信息，如通过返回值和get_last_error()机制传递，确保调用方安全获取错误详情，避免因编译环境不一致导致未定义行为。

在C++项目中，尤其是大型系统或模块化设计中，异常的跨模块传递是一个需要谨慎处理的问题。不同模块可能由不同团队开发，编译选项、异常支持状态（如是否启用RTTI和异常处理）也可能不同，直接抛出C++异常跨模块边界存在风险。因此，设置合理的异常边界是保障系统稳定的关键。

理解异常边界的必要性

当一个动态库（DLL或so）中抛出C++异常，而调用方在另一个模块中捕获时，若两边的运行时环境不一致（例如一个开启异常支持，另一个关闭），可能导致未定义行为，如程序崩溃或异常无法正确捕获。编译器对异常表（exception table）和栈展开机制的实现依赖于一致的编译配置。因此，在模块接口处应避免让C++异常“逃逸”到外部。

常见的模块边界包括：

• 动态链接库的导出函数（如DLL的extern "C"接口）
• 插件系统与宿主程序的交互点
• 不同语言间交互（如C++与C、Python绑定）

在模块接口处捕获并转换异常

推荐做法是在模块的最外层接口函数中使用try-catch块，将内部抛出的C++异常转换为安全的错误表示，如错误码或结构化错误信息。

示例：C风格导出接口的异常边界处理

假设有一个C++模块提供图像处理功能，并以C接口导出：

extern "C" {
    int process_image(const char* filename) {
        try {
            // 调用内部C++逻辑，可能抛出std::runtime_error等
            internal::process(filename);
            return 0; // 成功
        }
        catch (const std::invalid_argument& ) {
            return -1; // 参数错误
        }
        catch (const std::ios_base::failure& ) {
            return -2; // 文件读取失败
        }
        catch (...) {
            return -99; // 未知错误
        }
    }
}

这样，调用方（无论是C还是其他语言）只需检查返回值，无需处理C++异常。

提供异常信息传递机制

仅返回错误码可能不足以调试问题。可设计一个全局错误信息接口，供调用方在出错后查询详细信息。

static std::string last_error_msg;
extern "C" {
const char* get_last_error() {
return last_error_msg.c_str();
}
int process_image(const char* filename) {
    try {
        internal::process(filename);
        last_error_msg.clear();
        return 0;
    }
    catch (const std::exception& e) {
        last_error_msg = e.what();
        return -1;
    }
    catch (...) {
        last_error_msg = "Unknown exception occurred";
        return -99;
    }
}
}

这种方式在COM、Windows API等系统中广泛使用，如GetLastError()。

跨语言绑定中的异常转换

在使用Python（通过pybind11）、Java（通过JNI）等语言调用C++模块时，同样需要在绑定层设置异常边界。例如pybind11会自动将C++异常转换为Python异常，但需注册转换器：

py::register_exception<std::runtime_error>(m, "RuntimeError");

在JNI中，则需在本地方法中捕获C++异常，并调用env->ThrowNew()抛出Java异常。

基本上就这些。关键是不让C++异常穿透模块边界，统一在接口层收敛并转换为调用方可理解的错误形式。这样既保留了内部开发的便利性，又保证了接口的健壮性和兼容性。