对错误处理的思考¶

编程语言的错误处理¶

错误处理是指在编程语言中, 对程序运行中可能发生的错误（如语法错误、运行时错误、系统错误等）进行处理的过程。不同的编程语言提供了不同的错误处理机制, 如异常处理、错误码、调试信息等。正确的错误处理机制可以有效地帮助开发者定位和修复错误, 并保证程序的稳定性和可靠性, 实际生产过程中, 任何错误都要得到妥善处理, 否则会埋下隐患, 轻则影响体验, 重则带来安全问题。

对开发者来说, 错误处理包含这么几部分：

当错误发生时, 用合适的错误类型捕获这个错误。
错误捕获后, 可以立刻处理, 也可以传递错误延迟处理。
最后, 根据不同的错误类型, 给用户返回合适的、帮助他们理解问题所在的错误消息。

每当开始一个新项目时, 第一件要考虑的事应该是“我该如何管理错误”。

常见的三种错误处理方式如下：

返回值/错误码: 在程序中通过返回一个整数状态码来表示操作是否成功, 状态码为0表示操作成功, 其他值表示失败, 比较有代表性的时C语言的返回值及errno。
异常和断言: 返回值不利于错误的传播, 使用异常处理机制, 当程序发生错误时, 抛出一个异常, 程序的执行会被中断, 并从调用栈中向上回溯, 直到找到处理该异常的代码。
类型系统: 比较典型的是Rust , 在 Rust 中, 可以使用 Result 类型来表示函数的返回结果, 其中 T 表示成功的结果类型, E 表示错误的结果类型。如果函数执行成功, 则返回一个包含成功结果的 Ok 值, 如果执行失败, 则返回一个包含错误结果的 Err 值。

错误处理, 一直是编程语言的一个设计难点, 各种编程语言的错误处理机制都不尽相同, 并且各有优劣.

方式	优点	缺点
返回值/错误码	简单易用, 易于理解和实现	不易于描述复杂的错误状态, 可读性差, 容易出错（未检查的状态码）如果错误不及时处理, 又会丢掉这个错误信息, 造成隐患。
异常和断言	能够描述复杂的错误状态, 易于使用, 提高可读性	程序性能可能降低（抛出和捕获异常的代价）, 不适用于所有编程语言, 需要统一的异常处理机制,开发者会滥用异常不适用于检测所有的错误, 不能描述复杂的错误状态, 仅在调试阶段有效(assertions)
类型系统	通过返回值返回错误, 但是错误被包裹在一个完整的、必须处理的类型中, 代码可读性好,代码简洁高效	需要掌握后,才会带来生产效率的提升.

请注意, 不同的编程语言和应用场景可能会有所不同, 因此上述比较仅是一般趋势。

Rust语言的错误处理¶

Rust 偷师 Haskell, 构建了对标 Maybe 的 Option 类型和对标 Either 的 Result 类型。可以说是十分的优雅, 特别体现在对Option和Iterator的交互上, 但是对于新人入门来说需要一定的学习成本。

Option 是一个 enum, 其定义如下：

pub enum Option<T> {
    None,
    Some(T),
}

它可以承载有值/无值这种最简单的错误类型。

Result 是一个更加复杂的 enum, 其定义如下：

#[must_use = "this `Result` may be an `Err` variant, which should be handled"]
pub enum Result<T, E> {
    Ok(T),
    Err(E),
}

当函数出错时, 可以返回 Err(E), 否则 Ok(T)。

此外, Rust还提供?运算符来方便的传递错误, 需要实现 From trait 在二者之间建立起转换的桥梁, 这会带来额外的麻烦。Rust 还为 Option 和 Result 提供了大量的辅助函数, 如 map / map_err / and_then, 你可以很方便地处理数据结构中部分情况。

无论是通过 ? 操作符, 还是函数式编程进行错误处理, Rust 都力求让错误处理灵活高效, 让开发者使用起来简单直观。

对于不可恢复类的错误, 使用 panic! / catch_unwind 来应对,提供了特殊的异常处理能力。

我们讲到 Result 里 E 是一个代表错误的数据类型。为了规范这个代表错误的数据类型的行为, Rust 定义了 Error trait：

pub trait Error: Debug + Display {
    fn source(&self) -> Option<&(dyn Error + 'static)> { ... }
    fn backtrace(&self) -> Option<&Backtrace> { ... }
    fn description(&self) -> &str { ... }
    fn cause(&self) -> Option<&dyn Error> { ... }
}

我们可以定义我们自己的数据类型, 然后为其实现 Error trait。如果不借助第三方rust库, 要构筑好自己的Error错误处理是一个繁琐切精细的工作.

错误处理中常见问题¶

在错误处理中, 常见的问题包括：

未考虑所有可能的异常情况
忽略错误信息, 导致难以诊断问题
过于简单的错误处理逻辑, 导致系统不稳定
过于复杂的错误处理逻辑, 导致代码难以维护
对已知错误的不当处理, 导致系统更加不稳定
缺乏对错误跟踪和分析的机制, 导致难以快速定位错误原因
不合理的错误处理策略, 导致系统行为不可预期。

解决错误处理中的问题通常需要以下步骤：

定义错误：确定错误的类型和原因。
收集数据：收集有关错误的信息, 如日志, 调用堆栈和环境变量。
分析数据：分析错误的原因, 以及需要执行哪些步骤来解决问题。
解决问题：使用解决方案, 如代码修复, 配置更改或更新软件。
测试解决方案：验证解决方案是否有效, 并确保错误不再发生。
更新文档：更新错误处理流程的文档, 以便在未来的问题出现时使用。

这些步骤可以通过使用工具, 如调试器, 错误日志分析器和问题跟踪系统等, 来加速和简化。

除了上面常见的使用问题外,在日常使用过程中,我们在设计错误处理时, 要面临几个比较关键的问题.

多种类型的Error在同一个函数中需要处理时, 必须要有一个共同的可以Into的Error类型作为函数返回值, 比如下面的代码：

fn foo() -> Result<(), FooError> {
    let one: Result<(), OneError> = fn_one();
    one?;

    let two: Result<(), TwoError> = fn_two();
    two?;

    Ok(())
}

那么FooError必须有实现From和From, 惯常的做法是写一个enum将所有的错误都封装起来, 并且实现Display、Debug、Error还有From这几个trait, 手写的话比较枯燥乏味。

Error trait的backtrace还未稳定, 虽然说backtrace对性能会有损耗, 但是没有backtrace在遇到错误抛出的时候, 如果错误没有一些明确的信息, 就很难定位到是哪里的代码抛的这个错误, 特别是对于第三方库抛的错误, 对于开发调试和生产排查问题都造成了不便, 在Fix the Error trait这个RFC里面有提出。
模块级 Error 类型与全局 Error 类型.模块级 Error 类型：指的是在单个模块内部使用的错误类型, 只对该模块内的代码有效, 不会影响到其他模块。模块级 Error 类型可以使代码更容易维护和阅读, 并且更容易诊断错误。全局 Error 类型：指的是在全局范围内使用的错误类型, 对整个程序有效。全局 Error 类型可以使代码具有更高的可移植性, 因为它可以在任何模块中使用, 但它可能会使代码难以维护, 因为所有错误类型都存在于全局范围内。这是在大型工程中经常要面临的问题, 要根据实际情况做出些取舍.

对于上面的问题, Rust界很多很优秀的crates来解决,通过宏来简化Error的定义和使用.

这里重点介绍下两套方案, 两者都对上面问题有自己独到的见解.

thiserror + anyhow

注意事项：thiserror是给lib使用的, 而anyhow是给bin程序使用, 当然bin程序可以使用thiser+anyhow, 但是切记anyhow不要在lib里面使用。

use thiserror::Error;

#[derive(Error, Debug)]
pub enum DataStoreError {
    #[error("data store disconnected")]
    Disconnect(#[from] io::Error),
    #[error("the data for key `{0}` is not available")]
    Redaction(String),
    #[error("invalid header (expected {expected:?}, found {found:?})")]
    InvalidHeader {
        expected: String,
        found: String,
    },
    #[error("unknown data store error")]
    Unknown,
}

这个本质上用enum封装的思路, 用derive macro来自动生成的, 节省了很多的时间。

use anyhow::Result;

fn get_cluster_info() -> Result<ClusterMap> {
    let config = std::fs::read_to_string("cluster.json")?;
    let map: ClusterMap = serde_json::from_str(&config)?;
    Ok(map)
}

这里直接将anyhow::Result作为返回值, 因为它直接实现了From where E: Error, 所以无要维护一个enum类型, 但是注意只有在bin程序里面才建议使用.

snafu

snafu方案, 时将context和具体的Error比较优雅的结合起来. 还可以附带更多的错误相关信息, 如io::Error中可以附带PathBuf信息,比thiserror中直接继承更有意义.

#![allow(unused)]
fn main() {
use snafu::{ResultExt, Snafu};
use std::{fs, io, path::PathBuf};

#[derive(Debug, Snafu)]
enum Error {
    #[snafu(display("Unable to read configuration from {}: {}", path.display(), source))]
    ReadConfiguration { source: io::Error, path: PathBuf },

    #[snafu(display("Unable to write result to {}: {}", path.display(), source))]
    WriteResult { source: io::Error, path: PathBuf },
}

type Result<T, E = Error> = std::result::Result<T, E>;

fn process_data() -> Result<()> {
    let path = "config.toml";
    let configuration = fs::read_to_string(path).context(ReadConfiguration { path })?;
    let path = unpack_config(&configuration);
    fs::write(&path, b"My complex calculation").context(WriteResult { path })?;
    Ok(())
}

fn unpack_config(data: &str) -> &str {
    "/some/path/that/does/not/exist"
}
}

不妨通过官网来了解snafu的设计哲学.

同样的底层错误可以根据上下文不同而转换为不同的领域特定错误, 例如同样是 io 错误, 根据上层业务语义的不同能够转换为不同的业务错误
在库和应用的场景下都同样好用
模块级别的 Error 类型, 每个模块都应该定义一个, 甚至多个自己专用的错误类型

sysMaster错误处理¶

我们过去熟悉的初始化系统（比如 sysVinit、systemd、upstart）, 大多是使用 C 写的, 且往往因为设计复杂, 功能大一统等有违 UNIX 传统思维的做法而广受诟病。openEuler 社区为社区提供了一个全新的、采用 Rust 编写的初始化系统 —— sysMaster。

和 systemd 相比, 由于 sysMaster 采用 Rust 语言编写, 原生地规避了内存泄漏问题, 开发者无需担心内存泄漏导致的 1 号进程挂掉。而从零构建的 sysMaster, 也摒弃了之前的初始化系统中存在问题, 为开发者提供了**新一代的初始化系统** 。

相比于过去的初始化系统, sysMaster 提供了全新的架构设计, 分为 sysMaster Core 和 sysMaster Extend 两类。sysMaster Core 提供了极度轻量的调度方式, 占用更少的资源, 以及更快的启动速度。拆分的架构则可以支持拓展多种服务类型, 实现 1+1+N 的架构, 满足初始化系统的多样化诉求。而它的生态兼容工具, 则可以让开发者可以自由选择 systemd 和 sysMaster, 无需担心被生态绑定。

先摆观点,sysMaster中的错误处理要遵循下面的原则.

Error类型尽量做到模块级别, 类型定义尽量内聚且避免语义重复
建议使用snafu, 按crate单独定义对应的error.rs, 尽量避免函数级或文件级粒度

鉴于sysMaster大型软件的属性及独有的设计, 这是不使用全局的Error的原因, 因为会导致整个项目耦合比较高,不易维护.

下面重点阐述如何在项目中应用这些原则.

不会定义全局的error lib, 每个crate定义自己的error.rs, crate内只能使用这个统一的Error, 注意语义不能重复.sysmaster中,unit coms组件和sysmaster-core在逻辑和功能上共用一个Error,避免频繁的转换

//! Error define
use snafu::prelude::*;

/// Event Error
#[derive(Debug, Snafu)]
#[snafu(visibility(pub(crate))] //将可见性限制在内部
#[non_exhaustive] //申明结构体可变,未来添加更多属性
pub enum Error {
    /// An error from IO, can throw with more information
    #[snafu(display("Error(A-Io)"))]
    Io {
        source: std::io::Error,
        words: &'static str,   // 额外的错误信息
        backtrace: Backtrace,
    },

    /// It cannot be processed at this level and needs to be thrown. Be careful not to repeat semantics
    #[snafu(display("Error(event): '{}'.", word))]
    InvalidLoad {
        /// some words
        msg: &'static str,
    },
}

统一使用snafu来简化Error的定义, 并控制好作用域, 错误尽量在调用的地方同步处理掉, 尽量避免?和unwrap().

//! a_crate/error.rs
#[snafu(visibility(pub)] //将可见性限制在内部
#[non_exhaustive] //申明结构体可变,未来添加更多属性
pub enum Error {
    #[snafu(display("Error(A-Io)"))]
    Io {
        source: std::io::Error,
        words: &'static str,   // 额外的错误信息
        backtrace: Backtrace,
    },
    #[snafu(display("Error(event): '{}'.", word))]
    Other {
        words: &'static str,
    },
}

/// crate内部使用范例
pub fn inner_example() -> std::result::Result<(), Error> {
    std::fs::File::open("./io.rs").context(IoSnafu { word: "todo!()" })?;
    // open函数对应的错误时std::io::Error,否则无法使用context自动转化
    match condition() {
            casea => Ok(()),
            _ => OtherSnafu { words: "some words" },
            // OtherSnafu定义在crate内部, 需声明#[snafu(visibility(pub(crate)]
        }
    Ok(())
}

//! b_crate/error.rs 依赖a-crate
pub enum Error {
    #[snafu(display("Error(B-Io)"))]
    AError {
        source: a_crate::error::Error,
        more_words: &'static str,   // 使用界面产生更多额外的错误信息
        backtrace: Backtrace,
    },
}

/// 跨crate使用范例
fn example() -> std::result::Result<(), Error> {
    a_crate::inner_expamle().context(AErrorSnafu { more_word: "()" })?;
    // inner_expamle()对应错误时a_crate::error::Error, 否则无法
    // 同时要注意#[snafu(visibility(pub)]定义的a_crate的可见性, 如果使用a_crate::error::Error::Io
    Ok(())
}

snafu其他用法(如backtrace/宏)可以参考官方文档.

最后更新: March 29, 2023
创建日期: February 8, 2023