从C++转向Rust：两大主题值得关注！
The following article is from 云加社区 Author 孟杰
导语 | 云加社区祝大家新年快乐！新春假期结束的第一篇干货，为大家带来的是从C++转向Rust主题的内容。在日常的开发过程中，长期使用C++，在使用Rust的过程中可能会碰到一些问题。本文是From C++ To Rust的第二篇，在这一篇里，主要介绍错误处理和生命周期两个主题。
此前，我介绍了其中思维方式的转变（mind shift）：《详细解答！从C++转向Rust需要注意哪些问题？》
一、错误处理
（一）C++
任何生产级别的软件开发中，错误处理都需要被妥善考虑。C++通常会有两种错误处理的风格：
从C继承下来的返回值风格。所有函数都返回整型，用错误码来表示各种错误情况。
C++的异常，在出错的位置抛出异常，然后在错误处理的位置捕捉异常。
这两种方案各有优劣，这里简单地说明一下。
返回值风格的优点是清晰，错误发生的位置和处理方法都写得很直白；缺点即是拖沓，错误代码与业务代码交错在一起，使得主要逻辑不突出。同时占用了返回值位置，影响逻辑的表达。另外，没有强制错误检查，可能会遗漏错误检查而导致代码缺陷。如下：
if (OK != foo()) { // error handle}
SomeThing thing;if (OK != getSomeThing(&thing)) { // error handle}
thing.init(); // 可能已经失败了thing.action(); // 由于前面忘记检查是否成功初始化，这里可能会故障异常恰恰相反，错误有独立的处理流，通常不与业务逻辑相交，使得业务逻辑看起 来很清晰；但是由于异常的隐性，使得任何位置都可能抛出异常，函数的退出点也变得隐晦，带来异常安全问题，增加了代码编写的心智负担。如下：
void foo() { auto thing = new Thing(); bar(); // 可能会抛出异常 delete thing;}如果上面代码中的bar抛出异常，程序的执行流程将从bar函数跳出进入异常处理流程，因此后面delete语句不能得到执行，导致thing泄漏。
解决此问题的方法是使用智能指针，它们使用了RAII机制确保了函数在各种情况下均能妥善地释放动态分配的对象。
（二）Rust
Result<T，E>
Rust没有提供异常机制，与使用Option来解决可选的情况类似，它使用了Result来提供此功能。Result的定义如下：
pub enum Result<T, E> { /// Contains the success value Ok(T), /// Contains the error value Err(E),}可以看到，Result的定义几乎与Option一样。只是在异常的情况返回时多带一个错误类型。举一个具体的例子：
#[derive(Debug)]pub enum MyError { IoError(String), Inexist(String),}
pub type Result<T> = std::result::Result<T, MyError>;
pub fn fetch_id() -> Result<u64> { Ok(0)}
fn main() -> Result<()> { let id = fetch_id()?; println!("{:?}", id); Ok(())}上面let id=fetch_id()?；一句，使用了?操作符，实际相当于执行如下语句：
let id = match fetch_id() { Ok(id) => id, Err(err) => { return Err(err); }};相当于，如果被调函数(fetch_id)正常返回则unwrap其值；反之，则将被调函数的错误向上返回。
相对于C/C++，Rust在此处，实际上在尝试做到某种平衡：
没有异常，没有引入新的执行模型。函数的执行流程可以采用简单的返回值方式分析，便于理解。
?操作符的引入，使用语法糖一方面减少错误处理代码，代码更清爽；另一方面也显式地注明了所有返回点。
Result中携带的返回值T必须unwrap之后才能使用，这在类型系统上保证了错误必须被处理，不能沉默地忽略。
错误处理是强类型的。通过Result中的E类型参数向上返回错误时，必须要求E类型不变。这里产生了一些Rust错误处理的独特要求，后面再展开。
由于Safe Rust不能直接操作裸指针，所以不论函数从什么位置返回，均确保通过RAII机制释放了指针。
panic!
在Rust中，错误被划成了两类：可恢复的(recoverable) 和不可恢复的(unrecoverable)。所谓可恢复通常指的是可以上报给用户，修复之后，然后重试一下的错误，比如：文件未找到，配置错误等。而不可恢复一般是由于代码Bug导致的，程序已经进入未定义状态，继续执行可能产生未定义行为，比如：数组越界访问。
对于可恢复的错误，使用Result<T，E>返回错误，交由调用方决定该如何处理。而对于不可恢复的错误，使用panic!宏直接中止程序的执行。
（三）Rust错误处理惯例
如之前所说，Rust的错误处理是强类型的。因此，不能像C++的异常一样，错误可以穿透多层调用栈；相反，错误必须被逐层处理、翻译，不能一抛到底。这个工作其实是较为繁琐的。举个例子：
#[derive(Debug)]pub enum MyError { IoError(String), Inexist(String),}
pub type Result<T> = std::result::Result<T, MyError>;
pub fn fetch_id() -> Result<u64> { let content = std::fs::read_to_string("/tmp/tmp_id")?; let id = content.parse::<u64>()?; Ok(id)}这段代码不能编译通过，因为std::fs::read_to_string和String::parse的 返回值虽然都叫Result，但却不是相同的类型(因为E被定义为库局部的错误了)。因此，这里都不能直接使用?操作符。而是需要进行错误类型的翻译，转成我们自己定义的MyError：
pub fn fetch_id() -> Result<u64> { // 写法1： let content = match std::fs::read_to_string("/tmp/tmp_id") { Ok(content) => content, Err(_) => { return Err(MyError::IoError("read /tmp/tmp_id failed.".to_owned())); } }; // 写法2：使用标准库函数 map_err let id = content .parse::<u64>() .map_err(|_| MyError::ParseError("parse error.".to_owned()))?; Ok(id)}显然，写法1过入繁冗，实在称不上优雅。而写法2直接使用标准库函数map_err来完成错误类型的映射，会干净很多。但是如果映射的代码比较复杂，或者同样的处理会多次重复，就会希望将错误映射集的代码中起来。因此，社区中也提供了库来简化这部分处理，如：thiserror，anyhow。这两个库分别对应了库级别与应用级别的错误处理。
所谓库级别指的是编写为可被其它库或者应用复用的代码。因此，并不清楚错误最终会被如何处理，所以最终会在库级别统一Error的类型，并最终将底层转译到该错误类型。如上例中的MyError。上例在使用thiserror改写之后：
#[derive(thiserror::Error, Debug)]pub enum MyError { #[error("io error.")] IoError(#[from] std::io::Error), #[error("parse error.")] ParseError(#[from] std::num::ParseIntError),}
pub type Result<T> = std::result::Result<T, MyError>;
pub fn fetch_id() -> Result<u64> { let content = std::fs::read_to_string("/tmp/tmp_id")?; let id = content.parse::<u64>()?; Ok(id)}可以看使用thiserror后，代码清爽了很多。thiserror会为MyError自动实现底层Error的From trait。所以在fetch_id中就可以直接用?操作符将底层 Error映射到MyError。
而应用级别的Error不需要进一步上传给调用者，只需要有一个Result类型 可以集中处理所有的底层Error即可。因此，此时不需要自定义MyError， 使用anyhow改写之后如下：
use anyhow::{Context, Result};
pub fn fetch_id() -> Result<u64> { let content = std::fs::read_to_string("/tmp/tmp_id") .context("open /tmp/tmp_id failed.")?; let id = content.parse::<u64>().context("parse error.")?; Ok(id)}
fn main() -> Result<()> { let id = fetch_id()?; println!("{:?}", id); Ok(())}anyhow为泛型(generic)的Result<T，E>实现了Context trait。而Context提供了context函数，将原来的Result<T，E>转成了Result<T，anyhow::Error>，最终在应用级别将错误类型统一到anyhow::Error上。
限于篇幅，这里不再对这两个库做更深入说明，更细致的说明可以参考以下详细文档：
Rust:Structuring and handling errors in 2020（https://nick.groenen.me/posts/rust-error-handling/）
thiserror（https://docs.rs/thiserror）
anyhow（https://docs.rs/anyhow）
二、生命周期
终于到这个主题了！显然生命周期是Rust最独特的特性，没有之一。虽然在各种语言都会定义对象的生命周期，但将其在语言中静态表达出来的只有Rust。因此，虽然早有接触，但是在Rust碰到还是会觉得陌生，甚至晦涩。在这里笔者尝试记录下自己学习这个概念的关键点，想到什么说什么，不会是一个系统的教程，只是记录C++的熟悉者容易忽略的一些点。
（一）谈谈生命周期
简单地说，生命周期就是一个对象的存续时间。对于支持引用的语言来说， 引用目标在使用时必须存在是程序正确运行的基础；同时因为计算机内有限的资源，所以在对象使用完毕后，必须尽早释放。生命周期可以手动管理，但是因为程序的复杂性，手动管理是一件成本很高并且易错的工作。所以也就诞生了各种自动管理生命周期的算法，当前典型的算法有两类，引用计数(RC)和垃圾收集(GC)。
而Rust实际是探索了第三种自动管理的方案：编译期的静态检查-BorrowChecker，它通过分析变量的定义域(Scope)与移动(Move)规则，来保证通过引用使用目标对象的安全性。(注：在NLL BorrowChecker引入后，定义域不再是严格的代码块)。
初次接触Rust，最奇怪的就是生命周期的记法了：'a。很陌生，很费解。为什么需要它？解决什么问题？说一下我的理解：
'a 是一种标记，BorrowChecker通过比较生命周期来保证引用的安全性；
一般地，所有引用都含有生命周期标记。只是因为避免语言过于繁冗，Rust允许开发在一些情况下省略该标记(Lifetime Elision)；
因为BorrowChecker工作在编译期，所以生命周期标记合并在泛型系统中，具体实现为泛型参数中的一项。
（二）生命周期省略-Lifetime Elision
Rust为了代码的清爽，允许开发在很多情况下都可以不使用生命周期标记。
这使得生命周期标记的出现场景比较微妙，比如：
fn print(s: &str);实际上应该理解为：
fn print<'a>(s: &'a str);该函数接受一个字符串的引用，显然，这个引用目标的生命周期一定可以覆盖 print的执行期，print并不需要对引用的生命周期做更特别的静态检查。因此，Rust允许省略这个生命周期标记。
具体的省略规则可以参考文档：Lifetime Elision
（https://doc.rust-lang.org/nomicon/lifetime-elision.html）
说一下我的理解：
首先定义了输入引用和输出引用，文档中为了严谨，描述得比较长。简单地说，除了函数返回的引用外，其它都是输入引用。然后依据以下规则省略引用：
规则1：每个输入引用都给予独立的生命周期；
规则2：如果只有一个输入引用，那么该引用的生命周期给到全部省略的输出引用；
规则3：如果是多个输入引用，并且其中有&self或者&mut self，那么self的生命周期给到全部省略的输出引用；
其它情况都是错误的，必须显式地进行生命周期标注。
虽然Rust允许开发省略标注，但是需要注意的是：Rust根据上面规则自动恢复的标注，有可能并不是你想要表达的目的。如文档中的例子：
fn substr(s: &str, until: usize) -> &str;应用规则2，取消省略之后：
fn substr<'a>(s: &'a str, until: usize) -> &'a str;在取子串的情形中，返回的子串生命周期与输入参数一致，因此，默认恢复的标注是合理的。但是如果是下面函数：
fn country_abbr(c: &str) -> &str { match c { "China" => "CN", "America" => "US", _ => "Unknown", }}应用规则2，取消省略后的签名是：
fn country_abbr<'a>(c: &'a str) -> &'a str;可以知道，返回的“CN”，“US”，“Unknown”的生命周期是'static，由于'static的长度比所有其它生命周期都长，因此，将其以&'a str的类型返回不会有编译错误。但是这个结果会缩小country_abbr的使用范围，这可能并不是我们想要的结果。如下代码会无法编译通过：
fn check_lifetime(abbr: &'static str) {}
check_lifetime(country_abbr("China"));所以，在了解了生命周期的省略规则后，country_abbr的签名应该写作：
fn country_abbr(c: &str) -> &'static str;另一个需要注意的地方是：对于接受多个引用参数的函数，每个引用的生命周期都是独立的。如下：
fn foo(bar: &str, baz: &str);应该应用规则1和规则2展开为：
fn foo<'a, 'b>(bar: &'a str, baz: &'b str);而不是:
fn foo<'a>(bar: &'a str, baz: &'a str);因为后期实际上要求了两个参数的生命周期必须是一样的， 因此施加了比前者更强的约束。
（三）子类化(Subtyping)与变型(Variance)
写下这个标题时，我心里也是没有什么底的：因为相对来说这是一些抽象及陌生的概念，使用简单且易于理解的语言将其说明白，对我来说是也很大的挑战。下面的说明都是使用自己理解的语言来表达的，不追求特别严谨精确，但希望易于理解。
子类化Subtyping
为了加快思考，人脑会将一些常用的推导变成直觉，不自觉地忽略底层的逻辑细节，子类化(Subtyping)就是其中一个例子。因为在C++中，子类关系通常在继承关系中体现，所以从C++转过来的话，很容易下意识地认为子类就是继承。而事实上，子类关系是比继承关系更一般的(generic)关系。或者换句话说，继承关系是子类关系的一种实现。
所以，在Rust中不能简单地将子类化理解为继承，需要重新整理一下。笔者从几个点来理解：
子类关系符合里氏替换原则。即是说，如果S是T的子类，那么类型为T的形参可以填入类型为S的实参。说人话：在需要使用某个类型的场合，也可以使用该类型的子类来代替。白话：子类比超类更有用。
在逻辑学中，内涵指概念所拥有的属性；而外延指的具备概念属性的事物。对应到类型系统，内涵指是某个类型的属性或方法；而外延指的是该类型的所有实例。所以，子类比超类有更多内涵，更少外延；而超类反之。
说了这么多，终于可以回到生命周期主题了。笔者在学习生命周期的过程中， 碰到第一个反直觉的结论是：'static是所有其它生命周期的子类，可以写作'static<: 'a ('a是任意任命周期)。你看：明明'static是最长最大最多的生命周期，为什么是子类？是小的那端？理解起来很不自然。
后来一句话解了我的疑惑：生命周期的长度体现的是内涵。这句话想想还有点哲学意味。
因此，<: 描述的是外延的大小，所以，任何大于'a的生命周期都是'a的实例，而'static的实例只有一个，就是'static本身。显然，'a的外延大于'static，所以'static是子类。从有用性的角度理解，'static可以在任何需要生命周期的地方使用，是最有用的，所以根据前面说到的，子类比超类更有用，'static显然是子类。
变型Variance
在介绍变型之前，需要先引入另外一个概念类型构造子(Type Constructor)。首先这个概念要与C++中的构造函数(Constructor)区别开来：构造函数是用于创建类型的新实例；而类型构造子则是用于创建新类型：
可以是和类型或者积类型的构造。在Rust中可以认为是enum或者struct的定义式；
可以是泛型类型的实例化。如：Vec<u8>。
在考虑变型时，主要是第二种情形，即：泛型类型的实例化。我们可以将泛型类型理解为类型的函数，因为其接收类型参数，返回新的类型。这样，我们就可以引出变型的三种情况了：
假设有类型构造子：F<T>, 并且有两个具体的类型：Super和Sub满足Sub<:Super，这两个具体类型通过F<T>可以分别构建新类型F<Sub>和F<Super>
协变-covariance: 如果新类型和类型参数的关系一致，即满足 F<Sub> <: F<Super>，则称之为F<T>对T协变。
逆变-contravariance: 如果新类型和类型参数的关系相反，即满足 F<Super> <: F<Sub>，则称之为F<T>对T逆变。
不变-invariance: 如果新类型和类型参数的关系无关，即不满足任何约束，则称之为F<T>对T不变。
终于介绍完了两个抽象概念，可以回来谈Rust了。
Rust当前没有定义类型间的子类关系。trait虽然可以继承，但并不是符合定义的子类关系（无法将&dyn Derive直接传给&dyn Base）。因此，在当前版本的Rust中，子类关系只在生命周期中存在。
在Rust的文档中，有一个表描述了各种类型的变型关系，这里针对不太容易理解的两种情况进一步说明：
&'a mut T为什么对T是不变(invariant)?
根据《锈灵书》在介绍变型的相关章节中提供的例子：
fn evil_feeder(pet: &mut Animal) { let spike: Dog = ...;
// `pet` is an Animal, and Dog is a subtype of Animal, // so this should be fine, right..? *pet = spike;}
fn main() { let mut mr_snuggles: Cat = ...; evil_feeder(&mut mr_snuggles); // Replaces mr_snuggles with a Dog mr_snuggles.meow(); // OH NO, MEOWING DOG!}&mut T对T的不变性(invariant) 是为了阻止通过修改超类的引用&mut Animal将Dog的实例复制到Cat的内存上(*pet=spike)。但是这个例子还是有一些不清晰的地方：
如前面所述，类型间的子类关系在Rust并未定义，所以这里上面提到“Dog is a subtype of Animal”并不准确。
另外，由于trait object是一个动态尺寸类型(dynamic sized type)，所以必须Dog，Cat必须位于某种指针之后，因此，let spike: Dog=...不是合法的代码。
从逻辑上说，拿到某个类的指针，并不能用子类(当然也不能用超类)实例去覆盖该类的实例，因此，&mut T应该是不变的(invariant)。笔者推测是否也是Rust为了保留以后类型子类化的能力。
fn(T)-> ()为什么对T是逆变(contravariant)?
这是文档中唯一的逆变的例子，所以多说明一下。fn(T) -> ()是函数类型，用该类型描述某个作用场景(即，参数位置)时，其实是回调的场景。因此，回调函数的参数类型T，实际是对调用方的要求。这个要求越少(即，更加泛化，约束少，更偏向超类)， 回调函数反而使用场景更大(即，更有用)。前面已经说到，更有用的是子类。
举个例子：
struct A;
fn foo(cb: fn(a: &A)) { let a = A; cb(&a);}
fn cb0(_a: &A) { println!("cb0 called.");}
fn cb1(_a: &'static A) { println!("cb1 called.");}
fn main() { foo(cb1);}这里cb1的参数类型&'statc A是cb0的参数类型&'a A的子类，但是cb1却不能被foo接受。
（四）关于生命周期容易产生的误解
在Rust中，生命周期是全新的概念，因此也容易理解错误，对于常见的情形，Common Rust Lifetime Misconceptions一文介绍得非常清楚。
文档：（https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md#3-a-t-and-t-a-are-the-same-thing）
如果刚开始学习Rust特别需要注意：
T既是&T也是&mut T的超类；
&T和&mut T是不相交的集合。
对于熟悉C++重载规则的开发来说，这两点是需要注意的。在Rust中，因为T包含&T，所以，不能同时为T，&T实现一个trait. 如下：
trait Trait {}
impl<T> Trait for T {}
impl<T> Trait for &T {} // ❌&mut T和T也同理。因此，要为引用实现trait应该写作：
trait Trait {}
impl<T> Trait for &T {} // ✅
impl<T> Trait for &mut T {} // ✅另外，即是要区分好，T: 'static和&'static T，主要规则如下：
T: 'static 应该读做：类型T被生命周期'static定界；
如果T: 'static, 那么，T可以是生命周期为'static的借用类型，或者是拥有所有权的类型。
因为T: 'static包括拥有所有权类型，所以T：
可以在运行时动态分配；
不必在程序运行的整个生命周期有效；
可以安全地被修改；
可以在运行时动态释放；
可以具备不同的存续期。
更加一般地，T: 'a和&'a T的规则如下：
T: 'a比 &'a T更具弹性且通用；
T: 'a可以接受拥有所有权的类型，包含引用的拥有所有权类型或者引用；
&'a T只接受引用；
如果T: 'static那么T: 'a因为对于所有'a有'static >='a。
三、后记
这两个主题比我想像花了更多的篇幅，所以这一篇先到这里吧。后面计划继续聊聊可修改性Mutablility和异步Async。
作者简介
孟杰
腾讯后台开发工程师
腾讯后台开发工程师，毕业于中南大学。目前负责腾讯安全流量分析平台的后台开发工作。开发经验丰富，对程序语言，类型系统，编译等方向很感兴趣。
参考阅读：
本文由高可用架构翻译。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。