Comprehensive Rust 实践指南Chromium 环境下 CXX 桥接的 Rust–C 错误处理方案【免费下载链接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.项目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust在 Comprehensive Rust 课程中Chromium 部分采用 CXX 工具描述 Rust 与 C 的语言边界但 CXX 原生的ResultT, E支持依赖 C 异常无法直接用于 Chromium 工程。本文基于课程文档 error-handling.md完整讲解 Chromium 团队对ResultT, E中成功值T与错误值E的替代传递策略并结合仓库中 QR 码生成器、PNG 解码器等真实桥接示例帮助读者掌握在不使用 C 异常的前提下设计安全、可落地的 FFI 错误处理接口。为什么 CXX 内置的ResultT, E在 Chromium 中不可用CXX 本身是支持ResultT, E的仓库中保留的 CXX 示例片段snippets.rs展示了标准用法——// ANCHOR: rust_result #[cxx::bridge] mod ffi { extern Rust { fn fallible(depth: usize) - ResultString; } } fn fallible(depth: usize) - anyhow::ResultString { if depth 0 { return Err(anyhow::Error::msg(fallible1 requires depth 0)); } Ok(Success!.into()) } // ANCHOR_END: rust_result #[cxx::bridge] mod ffi { unsafe extern C { include!(example/include/example.h); fn fallible(depth: usize) - ResultString; } } fn main() { if let Err(err) ffi::fallible(99) { eprintln!(Error: {}, err); process::exit(1); } }这套机制的工作原理是双向的异常转换Rust 返回Result在 C 侧被翻译为异常抛出。抛出的异常类型始终是rust::Error主要暴露一个获取错误消息字符串的接口错误消息来自 Rust 错误类型的Display实现而从 Rust 向 C 方向解绕unwind的 panic 会直接导致进程立即终止参见 rust-result.md。C 抛出异常声明为返回Result的 C 函数会在桥接层捕获任何被抛出的 C 异常并转换为 Rust 侧的Err值若异常来自未声明返回Result的extern C函数则程序调用std::terminate行为等价于该异常穿过noexcept函数参见 cpp-exception.md。问题在于CXX 的Result支持完全建立在 C 异常机制之上而 Chromium 不允许跨 FFI 边界使用 C 异常。因此需要为ResultT, E的两个组成部分分别设计替代传递方案。T部分成功值的两种替代方案方案一通过输出参数返回out parameters最直接的方式是把成功值通过mut T形式的输出参数传回 C 调用方。这要求T能够跨 FFI 边界传递具体而言T必须满足是原始类型如u32、usize或者是被cxx原生支持、且在失败情况下具有合适默认值的类型如UniquePtrT——注意这里BoxT是不行的因为Box没有可在失败时填入的零值。仓库中的 QR 码生成器示例error-handling-qr.md正是这一方案的落地成功结果可以跨 FFI 边界传递错误用布尔值表达——#[cxx::bridge(namespace qr_code_generator)] mod ffi { extern Rust { fn generate_qr_code_using_rust( data: [u8], min_version: i16, out_pixels: Pinmut CxxVectoru8, out_qr_size: mut usize, ) - bool; } }几个值得注意的细节out_pixels使用Pinmut CxxVectoru8而不是普通的mut。CXX 之所以对 C 数据上的可变引用需要Pin是因为 C 对象不像 Rust 对象那样可以被随意移动——C 对象内部可能包含自引用指针移动会导致悬垂。out_qr_size是 QR 码本身的尺寸像素而不是向量的长度——严格说它是向量长度的平方根语义上略有冗余。调用方必须在调用前完成out_qr_size的初始化。这与 C 不同在 Rust 中创建一个指向未初始化内存的引用本身就构成未定义行为UB而在 C 中只有实际解引用未初始化内存才会触发 UB。对照仓库中的完整 CXX 桥接示例blobstore/src/main.rs可以看到输出参数、UniquePtr返回、Pin等机制在同一桥接模块中的组合使用方式#[cxx::bridge(namespace org::blobstore)] mod ffi { struct BlobMetadata { size: usize, tags: VecString, } extern Rust { type MultiBuf; fn next_chunk(buf: mut MultiBuf) - [u8]; } unsafe extern C { include!(include/blobstore.h); type BlobstoreClient; fn new_blobstore_client() - UniquePtrBlobstoreClient; fn put(self: Pinmut BlobstoreClient, parts: mut MultiBuf) - u64; fn tag(self: Pinmut BlobstoreClient, blobid: u64, tag: str); fn metadata(self, blobid: u64) - BlobMetadata; } }方案二成功值保留在 Rust 侧仅通过引用暴露当T是一个 Rust 类型、无法跨 FFI 边界传递、也无法放进UniquePtrT时例如PngReader这类持有生命周期参数的 Rust 对象就必须把成功值保留在 Rust 侧只向 C 暴露引用。仓库中的 PNG 解码器原型error-handling-png.md完整展示了这一模式——它本质上是在表达ResultPngReadera, ()的 FFI 友好等价物#[cxx::bridge(namespace gfx::rust_bindings)] mod ffi { extern Rust { /// This returns an FFI-friendly equivalent of ResultPngReadera, /// (). fn new_png_readera(input: a [u8]) - BoxResultOfPngReadera; /// C bindings for the crate::png::ResultOfPngReader type. type ResultOfPngReadera; fn is_err(self: ResultOfPngReader) - bool; fn unwrap_as_muta, b( self: b mut ResultOfPngReadera, ) - b mut PngReadera; /// C bindings for the crate::png::PngReader type. type PngReadera; fn height(self: PngReader) - u32; fn width(self: PngReader) - u32; fn read_rgba8(self: mut PngReader, output: mut [u8]) - bool; } }这一设计包含几个关键点PngReader与ResultOfPngReader都是 Rust 类型对象本身不能不带间接层地跨越 FFI 边界因此new_png_reader返回BoxResultOfPngReadera提供堆上间接寻址。C 侧不能按值存储 Rust 对象所以也不可能写out_parameter: mut PngReader这样的输出参数。手动单态化泛型CXX 不支持任意泛型或 C 模板但本例通过把ResultT, E手动特化monomorphize成一个非泛型的ResultOfPngReader类型绕过了这一限制。该类型作为转发器暴露is_err、unwrap_as_mut等方法内部转发到ResultT, E对应的方法is_err、unwrap、as_mut从而把 Rust 的错误语义完整地投射到 C 侧。bool依然出现在逐次读取的粒度上read_rgba8同样以布尔值返回成功/失败说明两种策略可以在同一接口中按方法粒度组合使用。E部分错误值的处理对错误侧课程的结论非常务实以布尔值返回是最常用的方案true表示成功false表示失败QR 示例的返回类型就是bool保留错误细节理论上可行但在实践截至目前中尚没有被 Chromium 侧的需求真正需要过。也就是说Chromium 的实际策略是成功值尽力传回 C失败与否用一个bool交代而不像 CXX 默认机制那样把错误消息封装进rust::Error异常对象。工程约束为什么 Rust 代码要留在叶子节点错误处理只是 CXX 局限性的一个切面。课程的 limitations-of-cxx.md 指出CXX 从根本上适合接口足够简单、可以完整声明且只使用std::unique_ptr、std::string、[u8]等原生支持类型的场景它有不少限制例如不支持 Rust 的Option类型、错误处理围绕 C 异常展开、函数指针使用起来很别扭。从源码结构看这些约束的后果是Rust 在 Chromium 中目前只能用于充分隔离的叶子节点leaf nodes而不适合任意复杂的 Rust–C 互操作。此外受组件构建的链接细节限制一个组件中的 Rust 代码还不能依赖另一个组件中的 Rust 代码这进一步强化了叶子节点的使用边界。因此课程给出的实操建议是在考虑把 Rust 引入 Chromium 的某个使用场景时好的起点是先起草语言边界的 CXX 桥接声明看看它是否足够简单——如果连#[cxx::bridge]都难以写出该场景大概率不适合当前阶段的 Rust 化。更多桥接写法可参考 example-bindings.md 与 interoperability-with-cpp.md。小结与选型速查场景成功值T传递方式失败E传递方式仓库示例T可跨 FFI原始类型 / 有默认值的 cxx 原生类型输出参数mut T、Pinmut CxxVectorT等返回boolfalse即失败QR 示例T为不能跨边界的 Rust 类型保留在 Rust 侧Box间接 仅暴露引用手动单态化转发Result方法is_err()等查询方法PNG 示例保留错误细节—理论可行实践中暂不需要error-handling.md掌握上述方案后读者即可在遵循 Chromium 禁用 C 异常这一硬约束的前提下为任意可能失败的 Rust 函数设计出类型安全、语义清晰的 CXX 桥接接口。【免费下载链接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.项目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考