FFI 中的 C/C++ 异常处理：try-catch 边界与堆栈展开的兼容性

FFI 中的 C/C++ 异常处理：try-catch 边界与堆栈展开的兼容性

各位编程领域的专家、开发者们，大家好！

今天，我们将深入探讨一个在跨语言互操作性（Foreign Function Interface, FFI）编程中，既常见又极其关键的话题：C/C++ 异常处理在 FFI 边界处的行为，特别是 try-catch 机制与堆栈展开（Stack Unwinding）的兼容性问题。这不仅仅是一个理论问题，它直接关系到我们程序的稳定性、资源管理以及在多语言混合环境中构建健壮系统的能力。

开篇：FFI 与异常处理的挑战

首先，让我们明确几个基本概念。

什么是 FFI？
FFI 是一种机制，允许一种编程语言编写的代码调用另一种编程语言编写的代码。例如，Python 程序调用 C 库，Java 程序通过 JNI 调用 C++ 动态链接库，或者 C# 程序通过 P/Invoke 调用原生 C++ 代码。FFI 的核心在于弥合不同语言之间的调用约定、数据表示、内存管理以及运行时环境的差异。

C/C++ 异常处理机制简介
C++ 提供了一套强大的异常处理机制，通过 throw、try、catch 关键字实现。当程序在运行时遇到异常情况时，可以抛出一个异常对象。运行时系统会沿着调用栈向上查找匹配的 catch 块。在查找过程中，这个过程被称为堆栈展开（Stack Unwinding）。在堆栈展开时，系统会负责调用在当前作用域内创建的局部对象的析构函数，以确保资源的正确释放（RAII, Resource Acquisition Is Initialization）。这依赖于底层编译器的实现和操作系统的 ABI（Application Binary Interface）。

为什么 FFI 边界处的异常处理是一个复杂问题？
复杂性源于以下几个核心冲突：

1. ABI 不兼容性： 不同的编译器、不同的操作系统，甚至同一操作系统上不同版本的编译器，都可能采用不同的 ABI 来实现 C++ 异常处理的堆栈展开机制。当异常跨越一个由不同 ABI 编译的代码边界时，这种不兼容性会导致堆栈展开失败。
2. 语言运行时差异： C++ 的异常处理依赖于 C++ 运行时库来管理异常对象、查找 catch 块和执行堆栈展开。其他语言（如 C、Python、Java、Rust）有自己的错误处理机制（错误码、特定异常类型、panic等）和运行时环境。这些运行时环境通常不理解或不兼容 C++ 的堆栈展开机制。
3. 未定义行为的风险： 当 C++ 异常跨越一个不兼容的 FFI 边界时，其后果是未定义行为。这可能导致程序崩溃、资源泄露（因为析构函数未被调用）、数据损坏，甚至潜在的安全漏洞。

因此，在 FFI 场景下，我们必须对异常处理采取格外谨慎的态度，并设计明确的策略来管理它们。

第一章：C++ 异常处理机制的深入理解

为了有效处理 FFI 中的 C++ 异常，我们首先需要对 C++ 异常机制有深入的理解。

异常的抛出与捕获 (throw, try-catch)

C++ 异常机制的核心是 throw 语句和 try-catch 块。
当一个 throw 语句被执行时，它会创建一个异常对象，并将控制权转移给最近的、能够处理该异常类型的 catch 块。

#include <iostream>
#include <stdexcept>
#include <string>

// 自定义异常类型
class MyCustomException : public std::runtime_error {
public:
    MyCustomException(const std::string& msg) : std::runtime_error(msg) {}
};

void might_throw_function(int value) {
    if (value < 0) {
        throw std::out_of_range("Value cannot be negative");
    }
    if (value == 0) {
        throw MyCustomException("Value cannot be zero (custom exception)");
    }
    std::cout << "Function processed value: " << value << std::endl;
}

int main() {
    try {
        might_throw_function(5);
        might_throw_function(-1); // This will throw
        might_throw_function(0);  // This will never be reached
    } catch (const std::out_of_range& e) {
        std::cerr << "Caught out_of_range exception: " << e.what() << std::endl;
    } catch (const MyCustomException& e) {
        std::cerr << "Caught MyCustomException: " << e.what() << std::endl;
    } catch (const std::exception& e) { // 捕获所有标准异常
        std::cerr << "Caught generic std::exception: " << e.what() << std::endl;
    } catch (...) { // 捕获所有其他未知异常
        std::cerr << "Caught an unknown exception." << std::endl;
    }

    std::cout << "Program continues after exception handling." << std::endl;

    return 0;
}

栈展开 (Stack Unwinding) 的原理

栈展开是 C++ 异常处理的关键部分。当一个异常被抛出但尚未被捕获时，C++ 运行时会在调用栈上逐层向上搜索匹配的 catch 块。在这个过程中，它会执行以下操作：

1. 销毁局部对象： 对于栈上每一层函数调用中那些在异常抛出点之后、但在 catch 块之前创建的局部对象，它们的析构函数会被调用。这确保了 RAII 原则得到遵守，从而避免资源泄露（如文件句柄、网络连接、内存等）。
2. 查找 catch 块： 运行时系统会检查每一层栈帧，看是否存在能够处理当前异常类型的 try-catch 块。一旦找到匹配的 catch 块，堆栈展开停止，控制权转移到该 catch 块。

ABI (Application Binary Interface) 的角色

堆栈展开的实现高度依赖于编译器的 ABI。ABI 定义了函数调用约定、数据布局、名称修饰（name mangling）以及异常处理机制的底层细节。

• 异常处理表（Exception Handling Tables）： 现代 C++ 编译器通常通过在可执行文件中嵌入异常处理表来实现堆栈展开。这些表包含了每个函数的信息，包括其 try 块的范围、catch 块的位置以及如何销毁局部对象（即析构函数的地址）。
• 平台特定机制：
  • Itanium C++ ABI： 广泛用于 Linux、macOS 和其他类 Unix 系统，以及 ARM 架构。它定义了详细的异常处理模型，包括用于堆栈展开的数据结构和算法。
  • Microsoft Visual C++ (MSVC) ABI： 在 Windows 上使用，其 C++ 异常处理通常与 Windows 的结构化异常处理（SEH）机制紧密集成。它也有自己的异常处理表格式和堆栈展开逻辑。
  • DWARF (Debugging With Attributed Record Formats)： 虽然主要是调试信息格式，但它也包含用于堆栈展开所需的信息，并经常与 Itanium ABI 协同工作。

不同 ABI 之间堆栈展开机制的差异是 FFI 异常处理问题的根源。一个由 GCC 编译的 C++ 库抛出的异常，其堆栈展开信息是按照 Itanium ABI 格式编码的。如果这个异常穿过一个由 MSVC 编译的 C 代码或一个完全不理解 C++ ABI 的其他语言运行时，那么这个运行时将无法正确解析这些信息，导致堆栈展开失败。

noexcept 关键字及其意义

C++11 引入了 noexcept 关键字，用于指示一个函数不会抛出任何异常。

• noexcept 声明的函数： 如果一个函数被声明为 noexcept，但它在运行时抛出了异常，那么程序会立即调用 std::terminate()，导致程序终止。这避免了堆栈展开的开销，并为编译器提供了优化机会。
• noexcept(true) / noexcept： 函数承诺不抛出异常。
• noexcept(false)： 函数可能抛出异常。
• 默认行为： 大多数函数默认是 noexcept(false)。析构函数和 operator delete 默认是 noexcept(true)（除非它们调用的某个函数不是 noexcept）。

在 FFI 场景中，noexcept 具有重要的指导意义：

• FFI 边界函数应尽可能 noexcept： 如果你设计一个 FFI 接口，该接口函数应该被设计为不抛出 C++ 异常。如果它内部调用了可能抛出异常的 C++ 代码，那么它应该在 C++ 内部捕获并处理这些异常，然后以 FFI 友好的方式（如错误码）返回结果。
• 清晰的契约： noexcept 为 FFI 调用者提供了一个清晰的契约，即不必担心 C++ 异常从这个函数中逸出。

// 示例：使用 noexcept
void safe_noexcept_function() noexcept {
    // 这里的代码不应该抛出异常
    // 如果抛出，std::terminate() 会被调用
    std::cout << "This function is noexcept." << std::endl;
}

void potentially_throwing_function() {
    std::cout << "This function might throw." << std::endl;
    // throw std::runtime_error("Oops!"); // 实际场景中可能抛出
}

// FFI 包装器，确保不抛出异常
extern "C" int ffi_safe_wrapper_function(int input) noexcept {
    try {
        if (input < 0) {
            throw std::out_of_range("Input cannot be negative");
        }
        potentially_throwing_function();
        // ... 其他 C++ 逻辑
        return 0; // 成功
    } catch (const std::exception& e) {
        std::cerr << "Error in ffi_safe_wrapper_function: " << e.what() << std::endl;
        return -1; // 失败，返回错误码
    } catch (...) {
        std::cerr << "Unknown error in ffi_safe_wrapper_function." << std::endl;
        return -2; // 未知错误
    }
}

第二章：FFI 基础与边界的定义

什么是 FFI 边界？

FFI 边界是不同语言或不同编译单元之间代码调用的接口点。例如：

• 一个 C 程序调用一个 C++ 动态链接库中的 extern "C" 函数。
• 一个 Java JNI 方法调用一个 C/C++ 函数。
• 一个 Python ctypes 调用一个 C 库函数。

在这个边界上，所有跨语言的约定都必须得到遵守，包括函数签名、数据类型、内存布局和错误处理。

常见的 FFI 场景

调用方语言	被调用方语言	典型 FFI 机制	异常处理挑战
C	C++	extern "C" 包装器	C 不理解 C++ 异常
C++	C	直接调用	C 代码抛出的 SEH/信号可能不被 C++ 捕获
Python	C/C++	ctypes, cffi	Python 不理解 C++ 异常
Java	C/C++	JNI	JNI 需将 C++ 异常转换为 Java 异常
Rust	C/C++	unsafe extern "C"	Rust 的 panic 与 C++ 异常不兼容
C# (.NET)	C/C++	P/Invoke (DllImport)	.NET 需处理原生异常

调用约定 (Calling Conventions)

调用约定定义了函数如何传递参数、如何返回结果以及谁负责清理栈帧。常见的调用约定包括：

• cdecl：C 语言的默认约定，调用方清理栈。
• stdcall：Windows API 的默认约定，被调用方清理栈。
• fastcall：通过寄存器传递参数以提高速度。

在 FFI 中，确保调用方和被调用方使用相同的调用约定至关重要，否则会导致栈损坏和程序崩溃。extern "C" 关键字通常确保 C++ 函数使用 C 语言的默认调用约定（通常是 cdecl）。

// C++ 代码
// extern "C" 确保函数使用 C 语言的名称修饰和调用约定
extern "C" int add(int a, int b) {
    return a + b;
}

// C 代码
// 声明与 C++ 库中函数签名和调用约定一致
extern int add(int a, int b);

int main() {
    int result = add(10, 20);
    // ...
    return 0;
}

数据封送 (Data Marshaling)

数据封送是将一种语言的数据类型转换为另一种语言可理解的数据类型的过程。这包括基本类型（整数、浮点数）和复杂类型（字符串、结构体、数组）。

• 基本类型： 通常直接映射，但要注意大小和符号（如 int 在 C++ 中是 4 字节，但在某些嵌入式 C 平台可能是 2 字节）。
• 字符串： C/C++ 字符串是 char* 或 const char*，以空字符结尾。其他语言可能使用不同的字符串表示（如 Java 的 String 对象、Python 的 str 对象）。在 FFI 边界，通常需要进行显式转换和内存管理。
• 结构体/对象： 必须确保内存布局（成员顺序、填充）在两种语言中兼容。C++ 类的实例不能直接跨 FFI 边界传递，因为 C++ 类包含虚表、继承等复杂概念，这些在其他语言中无法直接理解。通常，我们会传递不透明指针（void*）或简单的 C 风格结构体。

内存管理与所有权

在 FFI 中，内存管理是一个常见且复杂的陷阱。谁分配内存？谁释放内存？

• 如果 C++ 分配内存并返回给其他语言： C++ 库必须提供一个函数来释放这块内存，而其他语言在不再需要时必须调用这个释放函数。
• 如果其他语言分配内存并传递给 C++： C++ 代码不应该尝试释放这块内存，除非它明确被告知要接管所有权。

原则： 内存的分配者也应该是其释放者，或者必须有明确的所有权转移协议。否则，容易导致双重释放、内存泄露或使用已释放内存的错误。

第三章：异常跨越 FFI 边界的风险与后果

现在，我们来详细探讨当 C++ 异常不加控制地跨越 FFI 边界时会发生什么。

ABI 不兼容性：不同编译器、不同操作系统、不同语言之间栈展开机制的差异

正如前面提到的，C++ 异常处理的底层实现是 ABI 相关的。

• C++ 异常与 C 异常 (SEH on Windows) 的区别：
  • C++ 异常 (例如 throw std::runtime_error) 是语言层面的机制，依赖 C++ 运行时库。
  • Windows SEH (Structured Exception Handling) 是操作系统层面的机制 (例如访问冲突、除零错误)。C++ 编译器通常会把 C++ 异常转换为 SEH 异常，以便操作系统能够处理，但反之则不一定。
  • 如果一个 C++ 异常跨越一个纯 C 代码编译的模块，而该模块没有 C++ 运行时库的支持，那么 C++ 异常的堆栈展开将无法进行。
• 栈展开信息的丢失或损坏： C++ 运行时需要在栈帧中查找特定的异常处理表条目来确定如何展开栈并调用析构函数。如果 FFI 边界的代码（例如，用 C 语言编写的，或者用与 C++ 库不同 ABI 编译的 C++ 代码）不理解这些信息，它就会简单地跳过这些栈帧，或者更糟的是，尝试以错误的方式解析它们，导致程序崩溃。

未定义行为：异常在不兼容的边界处传播的后果

当 C++ 异常跨越不兼容的 FFI 边界时，其后果是未定义行为。这意味着程序可能：

1. 资源泄露： 最常见的问题。由于堆栈展开失败，栈上局部对象的析构函数不会被调用。如果这些对象管理着文件句柄、网络连接、内存等资源，这些资源将永远不会被释放，导致系统资源耗尽。

   // C++ 库代码
   #include <fstream>
   #include <stdexcept>
   #include <iostream>
   
   class MyResource {
   public:
       std::ofstream file;
       MyResource(const std::string& filename) : file(filename) {
           if (!file.is_open()) {
               throw std::runtime_error("Failed to open file");
           }
           std::cout << "MyResource: File opened." << std::endl;
       }
       ~MyResource() {
           if (file.is_open()) {
               file.close();
               std::cout << "MyResource: File closed." << std::endl;
           }
       }
   };
   
   // 假设这是 FFI 导出的函数，但我们故意让它抛出异常
   extern "C" void dangerous_ffi_function() {
       MyResource res("temp_log.txt"); // 如果抛出异常，res 的析构函数应该被调用
       // ... 更多操作
       throw std::runtime_error("Intentional error in dangerous_ffi_function");
   }

   如果 dangerous_ffi_function 被一个纯 C 程序调用，并且异常未在 C++ 内部捕获，那么 MyResource 的析构函数将不会被调用，temp_log.txt 文件将永远不会被关闭，导致文件句柄泄露。

2. 程序崩溃： 堆栈展开失败通常会导致程序在尝试访问无效内存或执行无效指令时崩溃。C++ 运行时可能会检测到异常处理机制被破坏，然后调用 std::terminate()。

   // C 代码
   // 假设 dangerous_ffi_function 存在于一个 C++ 库中
   // 并且它会抛出 C++ 异常
   extern void dangerous_ffi_function(); // 没有 extern "C" 可能会有名称修饰问题，但假设已经处理
   
   int main() {
       printf("Calling dangerous FFI function...n");
       // 这里没有 C++ 异常处理机制
       dangerous_ffi_function(); // C++ 异常会直接穿透这里
       printf("Returned from dangerous FFI function.n"); // 这一行可能永远不会执行
       return 0;
   }

   当 dangerous_ffi_function 抛出异常时，C main 函数的调用栈无法理解 C++ 的堆栈展开机制。这通常会导致程序异常终止。

3. 数据损坏： 如果堆栈展开过程中，某些资源（如全局变量、静态变量）在析构函数中被修改，而析构函数未被调用，可能导致程序状态不一致，从而引发数据损坏。

4. 安全漏洞： 未定义的行为总是潜在的安全漏洞来源。攻击者可能会利用异常处理机制的缺陷来破坏程序执行流，从而执行恶意代码或绕过安全检查。

示例：简单 C++ 异常跨越 C 函数边界的灾难

my_cpp_lib.cpp (C++ 库):

#include <iostream>
#include <stdexcept>
#include <string>

// 一个简单的资源类，用于演示析构函数调用
class ScopedResource {
public:
    std::string name;
    ScopedResource(const std::string& n) : name(n) {
        std::cout << "ScopedResource '" << name << "' acquired." << std::endl;
    }
    ~ScopedResource() {
        std::cout << "ScopedResource '" << name << "' released." << std::endl;
    }
};

// 模拟一个会抛出异常的 C++ 内部函数
void internal_cpp_logic(int value) {
    ScopedResource res_internal("internal_logic_resource");
    if (value < 0) {
        throw std::runtime_error("Negative value not allowed in C++ logic!");
    }
    std::cout << "Internal C++ logic processed value: " << value << std::endl;
}

// 导出的 FFI 函数，故意不捕获异常
extern "C" void dangerous_ffi_entry(int value) {
    ScopedResource res_ffi("ffi_entry_resource"); // 这个资源应该被释放
    std::cout << "Entering dangerous_ffi_entry with value: " << value << std::endl;
    internal_cpp_logic(value); // 可能会抛出异常
    std::cout << "Exiting dangerous_ffi_entry normally." << std::endl;
}

// 导出的 FFI 函数，安全捕获异常
extern "C" int safe_ffi_entry(int value, char* error_msg_buffer, int buffer_size) {
    try {
        ScopedResource res_ffi_safe("safe_ffi_entry_resource");
        std::cout << "Entering safe_ffi_entry with value: " << value << std::endl;
        internal_cpp_logic(value);
        std::cout << "Exiting safe_ffi_entry normally." << std::endl;
        if (error_msg_buffer && buffer_size > 0) {
            error_msg_buffer[0] = ''; // 清空错误信息
        }
        return 0; // 成功
    } catch (const std::exception& e) {
        std::cerr << "Caught C++ exception in safe_ffi_entry: " << e.what() << std::endl;
        if (error_msg_buffer && buffer_size > 0) {
            // 将错误信息复制到缓冲区
            strncpy(error_msg_buffer, e.what(), buffer_size - 1);
            error_msg_buffer[buffer_size - 1] = '';
        }
        return -1; // 失败
    } catch (...) {
        std::cerr << "Caught unknown C++ exception in safe_ffi_entry." << std::endl;
        if (error_msg_buffer && buffer_size > 0) {
            strncpy(error_msg_buffer, "Unknown C++ exception", buffer_size - 1);
            error_msg_buffer[buffer_size - 1] = '';
        }
        return -2; // 未知错误
    }
}

main.c (C 语言调用方):

#include <stdio.h>
#include <stdlib.h> // For exit
#include <string.h> // For strncpy

// 声明 C++ 库中导出的函数
extern void dangerous_ffi_entry(int value);
extern int safe_ffi_entry(int value, char* error_msg_buffer, int buffer_size);

int main() {
    printf("--- Test Case 1: Calling dangerous_ffi_entry with valid value ---n");
    dangerous_ffi_entry(5);
    printf("--- dangerous_ffi_entry returned normally (expected). ---nn");

    printf("--- Test Case 2: Calling dangerous_ffi_entry with invalid value (EXPECT CRASH/LEAK) ---n");
    // 在这里，C++ 异常会穿透 C 边界。
    // ScopedResource 'ffi_entry_resource' 和 'internal_logic_resource' 的析构函数将不会被调用。
    // 可能会导致程序崩溃或资源泄露。
    dangerous_ffi_entry(-1);
    printf("--- dangerous_ffi_entry returned (UNEXPECTED, program might have crashed before this). ---nn");

    printf("--- Test Case 3: Calling safe_ffi_entry with valid value ---n");
    char err_buf[256];
    int result = safe_ffi_entry(10, err_buf, sizeof(err_buf));
    if (result == 0) {
        printf("safe_ffi_entry succeeded. No error.n");
    } else {
        printf("safe_ffi_entry failed with code %d. Error: %sn", result, err_buf);
    }
    printf("--- safe_ffi_entry returned normally. ---nn");

    printf("--- Test Case 4: Calling safe_ffi_entry with invalid value (EXPECT ERROR CODE) ---n");
    result = safe_ffi_entry(-5, err_buf, sizeof(err_buf));
    if (result == 0) {
        printf("safe_ffi_entry succeeded. No error.n");
    } else {
        printf("safe_ffi_entry failed with code %d. Error: %sn", result, err_buf);
    }
    printf("--- safe_ffi_entry returned normally. ---nn");

    printf("Program finished.n");
    return 0;
}

编译和运行：

# Linux/macOS (GCC/Clang)
g++ -fPIC -shared -o libmycpplib.so my_cpp_lib.cpp
gcc -o main main.c -L. -lmycpplib -Wl,-rpath=.

# Windows (MSVC)
cl /LD my_cpp_lib.cpp /Fe:mycpplib.dll
cl main.c mycpplib.lib

# 运行
./main  # 或 main.exe on Windows

预期输出：

• Test Case 1 会正常执行，两个 ScopedResource 都会被正确释放。
• Test Case 2 会在 dangerous_ffi_entry 中抛出异常。由于 C main 函数无法捕获 C++ 异常，程序很可能会在抛出异常后立即终止。你可能看不到 ScopedResource 'ffi_entry_resource' released. 的输出，这表明资源泄露。
• Test Case 3 和 4 会通过 safe_ffi_entry 正常执行，即使内部抛出异常，也会在 C++ 边界内被捕获并转换为错误码和错误信息返回给 C 调用者，确保资源被正确释放。

这个例子清晰地展示了异常穿透 FFI 边界的危险。

第四章：避免异常跨越 FFI 边界的策略

为了构建健壮的 FFI 应用程序，核心原则是：C++ 异常不应该跨越 FFI 边界。 所有的 C++ 异常都应该在 C++ 代码内部被捕获和处理，然后以 FFI 友好的方式（如错误码、状态结构体、回调函数等）向调用方报告错误。

策略一：在 C++ 内部捕获并处理所有异常

这是最推荐和最安全的策略。

1. 将 C++ 异常转换为 C 风格的错误码。
这是最常见和最简单的方法。FFI 接口函数返回一个整数错误码（0 表示成功，非零表示失败）。

// C++ 库文件 (my_cpp_lib.cpp)
#include <iostream>
#include <stdexcept>
#include <string>

// 模拟一个可能抛出异常的 C++ 函数
void some_cpp_operation(int value) {
    if (value < 0) {
        throw std::invalid_argument("Value cannot be negative.");
    }
    if (value == 0) {
        throw std::runtime_error("Value cannot be zero.");
    }
    std::cout << "C++ operation succeeded with value: " << value << std::endl;
}

// FFI 接口函数，捕获所有 C++ 异常并返回错误码
extern "C" int perform_operation_with_error_code(int value) {
    try {
        some_cpp_operation(value);
        return 0; // 成功
    } catch (const std::invalid_argument& e) {
        std::cerr << "Caught invalid_argument: " << e.what() << std::endl;
        return 1; // 特定错误码
    } catch (const std::runtime_error& e) {
        std::cerr << "Caught runtime_error: " << e.what() << std::endl;
        return 2; // 特定错误码
    } catch (const std::exception& e) {
        std::cerr << "Caught generic std::exception: " << e.what() << std::endl;
        return 3; // 通用错误码
    } catch (...) {
        std::cerr << "Caught unknown exception." << std::endl;
        return 4; // 未知错误码
    }
}

// C 语言调用方 (main.c)
#include <stdio.h>

extern int perform_operation_with_error_code(int value);

int main() {
    int res;

    printf("Calling with 5:n");
    res = perform_operation_with_error_code(5);
    if (res == 0) {
        printf("Success!n");
    } else {
        printf("Failed with error code: %dn", res);
    }

    printf("nCalling with -1:n");
    res = perform_operation_with_error_code(-1);
    if (res == 0) {
        printf("Success!n");
    } else {
        printf("Failed with error code: %dn", res);
    }

    printf("nCalling with 0:n");
    res = perform_operation_with_error_code(0);
    if (res == 0) {
        printf("Success!n");
    } else {
        printf("Failed with error code: %dn", res);
    }

    return 0;
}

2. 将 C++ 异常转换为结构化错误信息。
仅仅返回错误码可能不足以提供足够的诊断信息。可以返回一个错误码，并通过输出参数传递一个错误消息字符串或一个错误结构体。

// C++ 库文件 (my_cpp_lib.cpp)
#include <iostream>
#include <stdexcept>
#include <string>
#include <vector>
#include <cstring> // For strncpy

// 定义 C 风格的错误结构体
struct CppError {
    int code;
    char message[256]; // 固定大小的缓冲区
};

void another_cpp_operation(int value, std::string& result_str) {
    if (value < 10) {
        throw std::out_of_range("Value must be at least 10.");
    }
    result_str = "Processed value: " + std::to_string(value);
}

// FFI 接口函数，通过输出参数传递错误信息
extern "C" int perform_operation_with_error_info(int value, char* out_buffer, int buffer_size, CppError* out_error) {
    std::string cpp_result;
    try {
        another_cpp_operation(value, cpp_result);

        // 成功时，复制结果到 out_buffer
        if (out_buffer && buffer_size > 0) {
            strncpy(out_buffer, cpp_result.c_str(), buffer_size - 1);
            out_buffer[buffer_size - 1] = '';
        }
        // 清空错误信息
        if (out_error) {
            out_error->code = 0;
            out_error->message[0] = '';
        }
        return 0; // 成功
    } catch (const std::exception& e) {
        std::cerr << "Caught C++ exception: " << e.what() << std::endl;
        if (out_error) {
            out_error->code = -1; // 通用错误码
            strncpy(out_error->message, e.what(), sizeof(out_error->message) - 1);
            out_error->message[sizeof(out_error->message) - 1] = '';
        }
        if (out_buffer && buffer_size > 0) {
            out_buffer[0] = ''; // 失败时不返回结果
        }
        return -1; // 失败
    } catch (...) {
        std::cerr << "Caught unknown C++ exception." << std::endl;
        if (out_error) {
            out_error->code = -2; // 未知错误码
            strncpy(out_error->message, "Unknown error occurred.", sizeof(out_error->message) - 1);
            out_error->message[sizeof(out_error->message) - 1] = '';
        }
        if (out_buffer && buffer_size > 0) {
            out_buffer[0] = '';
        }
        return -2; // 失败
    }
}

// C 语言调用方 (main.c)
#include <stdio.h>
#include <string.h>

// 声明 C 风格的错误结构体 (必须与 C++ 中的定义一致)
struct CppError {
    int code;
    char message[256];
};

extern int perform_operation_with_error_info(int value, char* out_buffer, int buffer_size, struct CppError* out_error);

int main() {
    char result_buffer[512];
    struct CppError error_info;
    int res;

    printf("--- Calling with 15 (expected success) ---n");
    res = perform_operation_with_error_info(15, result_buffer, sizeof(result_buffer), &error_info);
    if (res == 0) {
        printf("Success! Result: %sn", result_buffer);
    } else {
        printf("Failed with code %d. Error: %sn", error_info.code, error_info.message);
    }
    printf("n");

    printf("--- Calling with 5 (expected failure) ---n");
    res = perform_operation_with_error_info(5, result_buffer, sizeof(result_buffer), &error_info);
    if (res == 0) {
        printf("Success! Result: %sn", result_buffer);
    } else {
        printf("Failed with code %d. Error: %sn", error_info.code, error_info.message);
    }
    printf("n");

    return 0;
}

3. 使用回调函数传递错误。
对于异步操作或需要更复杂错误处理逻辑的场景，可以使用回调函数来通知调用方错误。

策略二：利用语言特定的 FFI 机制

不同的宿主语言有不同的 FFI 库和机制，它们对原生异常的处理方式也各不相同。

1. Python (ctypes/cffi):
Python 的 ctypes 和 cffi 库允许直接加载动态链接库并调用其导出的函数。它们本身不理解 C++ 异常。因此，你必须在 C++ 侧捕获异常并返回错误码或错误信息。

// my_cpp_lib.cpp (同上，使用 perform_operation_with_error_code)
// ...
extern "C" int perform_operation_with_error_code(int value) { /* ... */ }

# python_caller.py
import ctypes

# 加载库
lib = ctypes.CDLL('./libmycpplib.so') # Linux/macOS
# lib = ctypes.CDLL('./mycpplib.dll') # Windows

# 定义 C 函数的签名
# restype: 返回类型
# argtypes: 参数类型列表
lib.perform_operation_with_error_code.restype = ctypes.c_int
lib.perform_operation_with_error_code.argtypes = [ctypes.c_int]

def call_cpp_func(value):
    print(f"Calling C++ function with {value}:")
    error_code = lib.perform_operation_with_error_code(value)
    if error_code == 0:
        print("C++ function succeeded!")
    elif error_code == 1:
        print("C++ function failed: Invalid argument (code 1)")
    elif error_code == 2:
        print("C++ function failed: Runtime error (code 2)")
    else:
        print(f"C++ function failed with unknown error code: {error_code}")

call_cpp_func(5)
call_cpp_func(-1)
call_cpp_func(0)

2. Java (JNI – Java Native Interface):
JNI 允许 Java 代码调用原生 C/C++ 代码。JNI 提供机制来检测和抛出 Java 异常。

• ExceptionCheck(): 检查是否有待处理的 Java 异常。
• ExceptionOccurred(): 获取待处理的 Java 异常对象。
• ThrowNew(): 在 C/C++ 侧抛出一个新的 Java 异常。

当 C++ 代码被 JNI 调用时，如果 C++ 代码抛出异常，JNI 环境默认不理解 C++ 异常。你必须在 JNIEXPORT 函数内部捕获 C++ 异常，然后使用 ThrowNew 抛出对应的 Java 异常。

// my_cpp_jni_lib.cpp
#include <jni.h>
#include <iostream>
#include <stdexcept>
#include <string>

// 模拟一个可能抛出异常的 C++ 函数
void cpp_logic_for_jni(int value) {
    if (value < 0) {
        throw std::invalid_argument("JNI: Value cannot be negative.");
    }
    if (value == 0) {
        throw std::runtime_error("JNI: Value cannot be zero.");
    }
    std::cout << "C++ logic for JNI succeeded with value: " << value << std::endl;
}

// JNI 导出函数
JNIEXPORT void JNICALL Java_com_example_NativeLib_callCppWithException(JNIEnv *env, jobject obj, jint value) {
    try {
        cpp_logic_for_jni(value);
    } catch (const std::invalid_argument& e) {
        // 捕获 C++ 异常，转换为 Java 异常
        env->ThrowNew(env->FindClass("java/lang/IllegalArgumentException"), e.what());
    } catch (const std::runtime_error& e) {
        env->ThrowNew(env->FindClass("java/lang/RuntimeException"), e.what());
    } catch (const std::exception& e) {
        env->ThrowNew(env->FindClass("java/lang/Exception"), e.what());
    } catch (...) {
        env->ThrowNew(env->FindClass("java/lang/Error"), "Unknown C++ exception occurred.");
    }
}

// com/example/NativeLib.java
package com.example;

public class NativeLib {
    static {
        System.loadLibrary("my_cpp_jni_lib"); // 加载动态链接库
    }

    public native void callCppWithException(int value);

    public static void main(String[] args) {
        NativeLib lib = new NativeLib();

        System.out.println("--- Calling with 5 (expected success) ---");
        try {
            lib.callCppWithException(5);
            System.out.println("Java call to C++ succeeded.");
        } catch (Exception e) {
            System.err.println("Java caught exception: " + e.getClass().getName() + ": " + e.getMessage());
        }

        System.out.println("n--- Calling with -1 (expected IllegalArgumentException) ---");
        try {
            lib.callCppWithException(-1);
            System.out.println("Java call to C++ succeeded.");
        } catch (Exception e) {
            System.err.println("Java caught exception: " + e.getClass().getName() + ": " + e.getMessage());
        }

        System.out.println("n--- Calling with 0 (expected RuntimeException) ---");
        try {
            lib.callCppWithException(0);
            System.out.println("Java call to C++ succeeded.");
        } catch (Exception e) {
            System.err.println("Java caught exception: " + e.getClass().getName() + ": " + e.getMessage());
        }
    }
}

3. Rust (Foreign Function Interface):
Rust 的 FFI 默认假定 C 风格的接口，不理解 C++ 异常。Rust 自身的错误处理机制是 Result 枚举和 panic!。

• panic=abort： Rust 编译器配置 panic=abort 会在 panic 时直接终止程序，不进行堆栈展开。这在 FFI 场景中可以避免一些不兼容问题，但代价是失去了 panic 的堆栈展开清理能力。
• Result 枚举： Rust 的惯用错误处理方式是返回 Result<T, E>，其中 T 是成功值，E 是错误值。

因此，在 Rust 调用 C++ 库时，C++ 侧必须捕获异常并将其转换为错误码或错误结构体，以便 Rust 可以将其映射到 Result 枚举。

// my_cpp_lib.cpp (使用 perform_operation_with_error_code_and_msg)
// ...
extern "C" int perform_operation_with_error_code_and_msg(int value, char* out_msg_buf, int buf_len) {
    // ... 捕获异常，将错误消息写入 out_msg_buf ...
    try {
        some_cpp_operation(value);
        if (out_msg_buf && buf_len > 0) out_msg_buf[0] = '';
        return 0;
    } catch (const std::exception& e) {
        if (out_msg_buf && buf_len > 0) {
            strncpy(out_msg_buf, e.what(), buf_len - 1);
            out_msg_buf[buf_len - 1] = '';
        }
        return -1;
    } catch (...) {
        if (out_msg_buf && buf_len > 0) {
            strncpy(out_msg_buf, "Unknown C++ Error", buf_len - 1);
            out_msg_buf[buf_len - 1] = '';
        }
        return -2;
    }
}

// src/main.rs
use std::ffi::{CStr, CString};
use std::os::raw::c_char;

// 声明 C++ 库中的函数
extern "C" {
    fn perform_operation_with_error_code_and_msg(
        value: i32,
        out_msg_buf: *mut c_char,
        buf_len: i32,
    ) -> i32;
}

// Rust 包装器函数，将 C 风格错误码转换为 Result
fn rust_safe_wrapper(value: i32) -> Result<String, String> {
    let mut buffer = vec![0u8; 256]; // 256字节的缓冲区
    let result_code = unsafe {
        perform_operation_with_error_code_and_msg(
            value,
            buffer.as_mut_ptr() as *mut c_char,
            buffer.len() as i32,
        )
    };

    if result_code == 0 {
        Ok(String::from("Operation successful"))
    } else {
        let error_msg = unsafe {
            CStr::from_ptr(buffer.as_ptr() as *const c_char)
                .to_string_lossy()
                .into_owned()
        };
        Err(format!("C++ Error (code: {}): {}", result_code, error_msg))
    }
}

fn main() {
    println!("--- Calling with 5 (expected success) ---");
    match rust_safe_wrapper(5) {
        Ok(msg) => println!("{}", msg),
        Err(e) => eprintln!("{}", e),
    }

    println!("n--- Calling with -1 (expected failure) ---");
    match rust_safe_wrapper(-1) {
        Ok(msg) => println!("{}", msg),
        Err(e) => eprintln!("{}", e),
    }

    println!("n--- Calling with 0 (expected failure) ---");
    match rust_safe_wrapper(0) {
        Ok(msg) => println!("{}", msg),
        Err(e) => eprintln!("{}", e),
    }
}

4. C# (.NET P/Invoke):
.NET 的 P/Invoke 机制允许 C# 调用原生 DLL 中的函数。它能够捕获一些原生异常（如 SEH 异常），但对于 C++ 语言层面的异常，仍然建议在 C++ 侧捕获并转换。

// my_cpp_lib.cpp (使用 perform_operation_with_error_code_and_msg)
// ...
extern "C" int perform_operation_with_error_code_and_msg(int value, char* out_msg_buf, int buf_len) {
    // ... 捕获异常，将错误消息写入 out_msg_buf ...
}

// CSharpCaller.cs
using System;
using System.Runtime.InteropServices;
using System.Text;

public class NativeMethods
{
    // 导入 C++ 函数
    [DllImport("mycpplib.dll", CallingConvention = CallingConvention.Cdecl)] // Windows
    // [DllImport("./libmycpplib.so", CallingConvention = CallingConvention.Cdecl)] // Linux/macOS
    public static extern int perform_operation_with_error_code_and_msg(
        int value,
        [Out] StringBuilder outMsgBuf, // Out 属性用于字符串输出
        int bufLen
    );

    public static void Main(string[] args)
    {
        StringBuilder errorBuffer = new StringBuilder(256);
        int result;

        Console.WriteLine("--- Calling with 5 (expected success) ---");
        result = perform_operation_with_error_code_and_msg(5, errorBuffer, errorBuffer.Capacity);
        if (result == 0)
        {
            Console.WriteLine("C++ operation succeeded!");
        }
        else
        {
            Console.WriteLine($"C++ operation failed with code {result}. Error: {errorBuffer}");
        }

        Console.WriteLine("n--- Calling with -1 (expected failure) ---");
        result = perform_operation_with_error_code_and_msg(-1, errorBuffer, errorBuffer.Capacity);
        if (result == 0)
        {
            Console.WriteLine("C++ operation succeeded!");
        }
        else
        {
            Console.WriteLine($"C++ operation failed with code {result}. Error: {errorBuffer}");
        }

        Console.WriteLine("n--- Calling with 0 (expected failure) ---");
        result = perform_operation_with_error_code_and_msg(0, errorBuffer, errorBuffer.Capacity);
        if (result == 0)
        {
            Console.WriteLine("C++ operation succeeded!");
        }
        else
        {
            Console.WriteLine($"C++ operation failed with code {result}. Error: {errorBuffer}");
        }
    }
}

策略三：设计健壮的 C 接口

无论使用何种 FFI 机制，设计一个健壮的 C 风格接口是基础。

• 明确的错误码约定： 定义一套清晰的错误码，例如，0 表示成功，正数表示警告，负数表示严重错误。
• 输出参数用于错误描述： 提供 char* error_message_buffer, int buffer_size 这样的参数，让 C++ 库可以将详细的错误信息写入调用方提供的缓冲区。
• 避免在 C 接口函数中抛出异常： 这一点是核心。所有 FFI 接口函数都应该包装在一个 try-catch(...) 块中。

// FFI 接口设计示例
// C++ 代码
extern "C" {

// 定义错误码枚举 (在 C/C++ 共享头文件中定义)
enum MyLibErrorCode {
    MYLIB_SUCCESS = 0,
    MYLIB_ERROR_INVALID_ARGUMENT = -1,
    MYLIB_ERROR_RUNTIME = -2,
    MYLIB_ERROR_UNKNOWN = -99,
    // ... 更多具体的错误码
};

// 不透明指针，用于管理 C++ 对象实例
struct MyCppObject; // 前向声明

// 工厂函数：创建 C++ 对象实例
MyCppObject* mylib_create_object(int initial_value, char* error_msg_buffer, int buffer_size) noexcept;

// 成员函数：执行操作
int mylib_do_something(MyCppObject* obj, int param, char* error_msg_buffer, int buffer_size) noexcept;

// 析构函数：释放 C++ 对象实例
void mylib_destroy_object(MyCppObject* obj) noexcept;

} // extern "C"

这个设计模式确保了所有操作都是 noexcept 的，并且错误信息始终通过明确的错误码和字符串缓冲区传递。

第五章：特殊情况与高级主题

Windows SEH (Structured Exception Handling) 与 C++ 异常

在 Windows 上，C++ 异常与操作系统的 SEH 机制之间存在交互。

• _try, _except, _finally： MSVC 提供了这些关键字来处理 SEH 异常。这些机制与 C++ 的 try-catch 块是不同的，但可以协同工作。
• /EHa 编译器选项： MSVC 的 /EHa 选项（默认）允许 C++ catch(...) 块捕获异步的结构化异常（如访问冲突）。/EHsc (推荐) 只捕获同步的 C++ 异常。
• 将 SEH 转换为 C++ 异常： 可以编写一个 SEH 过滤器函数，将特定的 SEH 异常转换为 C++ 异常，然后由 C++ catch 块处理。

#include <windows.h>
#include <eh.h> // For _set_se_translator
#include <iostream>
#include <stdexcept>

// 自定义 C++ 异常，用于封装 SEH 异常
class SEHException : public std::runtime_error {
public:
    unsigned int se_code;
    SEHException(unsigned int code, const std::string& msg)
        : std::runtime_error(msg), se_code(code) {}
};

// SEH 翻译器函数
void se_translator(unsigned int code, EXCEPTION_POINTERS* info) {
    std::string msg = "SEH Exception caught: ";
    switch (code) {
        case EXCEPTION_ACCESS_VIOLATION: msg += "Access Violation"; break;
        case EXCEPTION_INT_DIVIDE_BY_ZERO: msg += "Divide by Zero"; break;
        // ... 其他 SEH 错误码
        default: msg += "Unknown SEH Code"; break;
    }
    throw SEHException(code, msg);
}

void cause_access_violation() {
    int* p = nullptr;
    *p = 10; // 导致访问冲突
}

extern "C" int ffi_call_with_seh_protection(int attempt_seh_violation) {
    // 注册 SEH 翻译器，确保只在当前线程生效
    _se_translator_function old_translator = _set_se_translator(se_translator);

    try {
        if (attempt_seh_violation) {
            cause_access_violation(); // 这会触发 SEH 异常
        } else {
            std::cout << "No SEH violation attempted." << std::endl;
        }
        // 恢复旧的翻译器 (重要!)
        _set_se_translator(old_translator);
        return 0; // 成功
    } catch (const SEHException& e) {
        std::cerr << "Caught SEHException: " << e.what() << " (Code: 0x" << std::hex << e.se_code << ")" << std::endl;
        _set_se_translator(old_translator); // 恢复
        return -1; // 失败
    } catch (const std::exception& e) {
        std::cerr << "Caught generic C++ exception: " << e.what() << std::endl;
        _set_se_translator(old_translator); // 恢复
        return -2; // 失败
    } catch (...) {
        std::cerr << "Caught unknown exception." << std::endl;
        _set_se_translator(old_translator); // 恢复
        return -3; // 失败
    }
}

这种机制允许 C++ 代码以 C++ 异常的形式处理一些操作系统级别的错误。但在 FFI 边界，仍然应该将其转换为错误码。

交叉编译与 ABI 兼容性

• 不同平台： Windows、Linux、macOS 的 ABI 完全不同。为每个平台单独编译库是强制性的。
• 不同编译器： 即使在同一操作系统上，GCC、Clang、MSVC 之间也可能存在细微的 ABI 差异。尽量使用同一编译器套件来编译 FFI 库及其所有 C++ 组件。
• C++ 标准库版本： C++ 标准库（libstdc++ 或 libc++）的版本差异也可能导致问题，尤其是在动态链接时。确保 FFI 库和宿主程序使用的 C++ 标准库是兼容的。

C++03 vs C++11/14/17/20 noexcept 的演变

• C++03 异常规范 (Exception Specifications)： throw() 用于声明函数不抛出异常。这是一个运行时检查，如果函数抛出异常，会调用 std::unexpected。由于其运行时开销和实用性不足，在 C++11 中被废弃，在 C++17 中被移除。
• C++11 noexcept： 引入 noexcept 替代 throw()。noexcept 是一个编译时保证。如果 noexcept 函数抛出异常，程序会直接调用 std::terminate()。这是为了提供编译时优化机会和更强的保证。

在 FFI 编程中，应始终使用现代 C++ 的 noexcept 关键字来明确函数的异常行为。

第六章：最佳实践与设计模式

错误处理范式选择：错误码 vs 异常

在 FFI 边界，错误码是首选。虽然 C++ 内部广泛使用异常，但在跨语言边界时，异常的成本和复杂性远超其收益。

• 错误码的优势：
  • 通用性： 几乎所有语言都支持整数返回码。
  • 可预测性： 行为明确，不依赖于复杂的运行时机制。
  • 性能： 没有异常处理的额外开销。
• 何时使用异常（在 C++ 内部）： 对于真正的、不可恢复的、程序无法继续正常执行的错误，C++ 异常仍然是更好的选择，因为它强制调用者处理错误，并且能利用 RAII 进行资源清理。

封装原则：在 C++ 层内部处理复杂性

将 C++ 库的内部复杂性（包括异常处理）封装在 C++ 边界内。向 FFI 调用者暴露一个简单、健壮且 C 兼容的接口。

设计模式：C++ Facade (外观) 模式

1. 核心 C++ 逻辑： 包含所有复杂的 C++ 类、模板、异常和 RAII。
2. C 包装器层 (Facade)：
   • 所有 FFI 导出的函数都位于这一层。
   • 这些函数使用 extern "C" 声明。
   • 它们捕获所有内部 C++ 异常。
   • 它们将 C++ 异常转换为 FFI 友好的错误表示（错误码、错误消息等）。
   • 它们处理 C++ 对象生命周期（通过不透明指针 void* 进行管理，并提供创建/销毁函数）。

测试策略：确保 FFI 边界的错误处理

• 单元测试： 针对 C++ 内部逻辑进行单元测试，确保其异常抛出和捕获行为正确。
• 集成测试： 编写 FFI 调用方的测试，模拟各种错误情况，确保 FFI 边界的错误码和错误信息能够被正确接收和处理。
• 模糊测试 (Fuzzing)： 对 FFI 接口进行输入模糊测试，以发现未预料到的错误和崩溃。

文档：明确 FFI 接口的错误处理行为

详细的文档是 FFI 成功的关键。清楚地说明：

• 每个 FFI 函数的返回码含义。
• 错误消息缓冲区的使用约定。
• 任何特定的内存管理规则（例如，谁负责释放字符串或结构体）。
• 不支持 C++ 异常跨越边界。

示例：一个更完整的 FFI 库设计模式

my_complex_lib.h (C/C++ 共享头文件)

#ifndef MY_COMPLEX_LIB_H
#define MY_COMPLEX_LIB_H

#ifdef __cplusplus
extern "C" {
#endif

// 错误码定义
typedef enum {
    MC_SUCCESS = 0,
    MC_ERROR_INVALID_ARG = -1,
    MC_ERROR_OUT_OF_MEMORY = -2,
    MC_ERROR_FILE_NOT_FOUND = -3,
    MC_ERROR_INTERNAL = -100, // 通用内部错误
    MC_ERROR_UNKNOWN = -999   // 未知错误
} MyComplexErrorCode;

// 错误信息缓冲区大小
#define MC_ERROR_MESSAGE_MAX_LEN 256

// 不透明指针，代表 C++ 内部的对象实例
typedef void* MyComplexObjectHandle;

// 函数声明
// 创建对象
MyComplexObjectHandle mc_create_object(const char* name, char* err_buf, int err_buf_len);

// 执行操作
int mc_process_data(MyComplexObjectHandle handle, int data, char* err_buf, int err_buf_len);

// 获取对象内部状态（示例）
int mc_get_status(MyComplexObjectHandle handle, char* err_buf, int err_buf_len);

// 销毁对象
void mc_destroy_object(MyComplexObjectHandle handle);

#ifdef __cplusplus
} // extern "C"
#endif

#endif // MY_COMPLEX_LIB_H

my_complex_lib.cpp (C++ 实现)

#include "my_complex_lib.h"
#include <iostream>
#include <stdexcept>
#include <string>
#include <vector>
#include <cstring>
#include <memory> // For std::unique_ptr

// 内部 C++ 类
class MyComplexObject {
private:
    std::string _name;
    int _counter;
    std::vector<int> _data;

public:
    MyComplexObject(const std::string& name) : _name(name), _counter(0) {
        std::cout << "MyComplexObject '" << _name << "' created." << std::endl;
        if (name.empty()) {
            throw std::invalid_argument("Object name cannot be empty.");
        }
    }

    ~MyComplexObject() {
        std::cout << "MyComplexObject '" << _name << "' destroyed." << std::endl;
    }

    void process(int value) {
        if (value < 0) {
            throw std::invalid_argument("Data value cannot be negative.");
        }
        if (value > 1000) {
            throw std::runtime_error("Data value too large for processing.");
        }
        _data.push_back(value);
        _counter += value;
        std::cout << "MyComplexObject '" << _name << "' processed data: " << value << ". Counter: " << _counter << std::endl;
    }

    int get_current_status() const {
        // 模拟一个可能失败的操作，例如文件读取失败
        if (_counter % 7 == 0 && _counter != 0) {
            throw std::runtime_error("Simulated internal status error.");
        }
        return _counter;
    }
};

// 辅助函数：将 C++ 异常信息写入 C 缓冲区
static void set_error_message(char* err_buf, int err_buf_len, const char* msg) {
    if (err_buf && err_buf_len > 0) {
        strncpy(err_buf, msg, err_buf_len - 1);
        err_buf[err_buf_len - 1] = '';
    }
}

// FFI 函数实现
MyComplexObjectHandle mc_create_object(const char* name, char* err_buf, int err_buf_len) noexcept {
    try {
        if (!name) {
            set_error_message(err_buf, err_buf_len, "Name cannot be null.");
            return nullptr;
        }
        // 使用 unique_ptr 管理 C++ 对象，并在 FFI 边界传递原始指针
        // 注意：这里我们返回裸指针，但内部用 unique_ptr 管理生命周期。
        // FFI 调用者通过 mc_destroy_object 来触发 unique_ptr 的 delete。
        auto obj = std::make_unique<MyComplexObject>(name);
        set_error_message(err_buf, err_buf_len, ""); // 清除错误信息
        return obj.release(); // 释放所有权，返回裸指针
    } catch (const std::invalid_argument& e) {
        set_error_message(err_buf, err_buf_len, e.what());
        return nullptr;
    } catch (const std::bad_alloc& e) {
        set_error_message(err_buf, err_buf_len, "Out of memory.");
        return nullptr;
    } catch (const std::exception& e) {
        set_error_message(err_buf, err_buf_len, e.what());
        return nullptr;
    } catch (...) {
        set_error_message(err_buf, err_buf_len, "Unknown error during object creation.");
        return nullptr;
    }
}

int mc_process_data(MyComplexObjectHandle handle, int data, char* err_buf, int err_buf_len) noexcept {
    try {
        if (!handle) {
            set_error_message(err_buf, err_buf_len, "Invalid object handle.");
            return MC_ERROR_INVALID_ARG;
        }
        MyComplexObject* obj = static_cast<MyComplexObject*>(handle);
        obj->process(data);
        set_error_message(err_buf, err_buf_len, "");
        return MC_SUCCESS;
    } catch (const std::invalid_argument& e) {
        set_error_message(err_buf, err_buf_len, e.what());
        return MC_ERROR_INVALID_ARG;
    } catch (const std::runtime_error& e) {
        set_error_message(err_buf, err_buf_len, e.what());
        return MC_ERROR_INTERNAL;
    } catch (const std::exception& e) {
        set_error_message(err_buf, err_buf_len, e.what());
        return MC_ERROR_UNKNOWN;
    } catch (...) {
        set_error_message(err_buf, err_buf_len, "Unknown error during data processing.");
        return MC_ERROR_UNKNOWN;
    }
}

int mc_get_status(MyComplexObjectHandle handle, char* err_buf, int err_buf_len) noexcept {
    try {
        if (!handle) {
            set_error_message(err_buf, err_buf_len, "Invalid object handle.");
            return MC_ERROR_INVALID_ARG;
        }
        MyComplexObject* obj = static_cast<MyComplexObject*>(handle);
        int status = obj->get_current_status();
        set_error_message(err_buf, err_buf_len, "");
        return status; // 返回状态值
    } catch (const std::runtime_error& e) {
        set_error_message(err_buf, err_buf_len, e.what());
        return MC_ERROR_INTERNAL; // 返回错误码
    } catch (const std::exception& e) {
        set_error_message(err_buf, err_buf_len, e.what());
        return MC_ERROR_UNKNOWN;
    } catch (...) {
        set_error_message(err_buf, err_buf_len, "Unknown error getting status.");
        return MC_ERROR_UNKNOWN;
    }
}

void mc_destroy_object(MyComplexObjectHandle handle) noexcept {
    try {
        // 使用 unique_ptr 接管裸指针，然后让它自动销毁对象
        // 确保 delete 发生在 C++ 运行时环境中
        std::unique_ptr<MyComplexObject> obj(static_cast<MyComplexObject*>(handle));
        // obj 会在离开作用域时自动调用析构函数
    } catch (...) {
        // 析构函数通常不应抛出异常，但为了 FFI 健壮性，捕获任何意外情况
        std::cerr << "Warning: Unknown exception during object destruction in FFI." << std::endl;
    }
}

这个模式提供了一个健壮的 FFI 接口：

• 所有 C++ 异常都在 C++ 内部捕获并处理。
• 错误通过 int 返回码和 char* 错误消息缓冲区传递。
• C++ 对象的生命周期通过不透明指针和明确的创建/销毁函数管理，避免了跨 FFI 的内存管理问题。
• 所有 FFI 导出函数都声明为 noexcept，向调用者保证不会有 C++ 异常逸出。

第七章：问答与常见陷阱

Q: 我能否直接让 C++ 异常跨越 C 语言边界？
A: 强烈不建议。这几乎总是会导致未定义行为，从而引发程序崩溃、资源泄露或数据损坏。

Q: extern "C" 关键字能解决异常问题吗？
A: 不能。extern "C" 只是影响名称修饰（name mangling）和函数调用约定，确保 C++ 函数可以被 C 链接器找到并以 C 兼容的方式调用。它对 C++ 异常处理的底层 ABI 机制没有影响。

Q: 异常处理的性能开销如何？
A: 异常处理确实有性能开销，尤其是在抛出和捕获异常时（因为它需要进行堆栈展开）。然而，现代 C++ 编译器在没有抛出异常的路径上（zero-cost exception handling）的开销非常小。在 FFI 场景中，由于我们建议在 C++ 内部捕获所有异常并转换为错误码，性能开销通常不是主要瓶颈，因为异常路径不常被触发。

常见陷阱：

1. 忘记在 C++ 包装器中捕获异常： 这是最常见的错误，导致 C++ 异常直接穿透 FFI 边界。
2. 在回调函数中抛出异常： 如果 C++ 库通过 FFI 调用宿主语言的回调函数，并且该回调函数是用 C++ 编写的并抛出异常，这同样会造成问题。回调函数也需要遵循异常不跨越 FFI 边界的原则。
3. 内存泄露： 即使捕获了异常，如果资源没有通过 RAII 或显式清理机制正确释放，仍然会导致内存或其他资源泄露。
4. C++ 对象生命周期管理不当： 在 FFI 边界传递 C++ 对象的裸指针时，必须确保有明确的创建和销毁函数，并且这些函数在正确的语言运行时环境中被调用。

尾声：关键的思考

C/C++ FFI 中的异常处理核心在于明确的边界管理。将 C++ 异常转换为 FFI 友好的错误表示是最佳实践。理解不同语言和平台的 ABI 差异至关重要，以确保构建稳定可靠的跨语言系统。