1. Rust 的错误返回机制
Rust 函数计算过程如果发生错误怎么办？Rust没有采取 C++ 的异常机制，而是允许直接返回错误信息。
这意味着，Rust 提供了错误返回机制，允许函数正常结束时返回计算结果，同时，如果计算过程中出现错误，也可以返回结果。这就是系统库提供的 Result 数据类型。如下面的示意函数：
fn my_function() -> Result<i32, MyError> {// 返回正常结果return Ok(123);// 或返回错误return Err(MyError::new(/*可能有参数*/));
}
2. Rust 的 Error 特性
这个机制中，比较难以理解的是 MyError 类型如何设计实现。实际上，Rust 要求用户自定义错误类型实现 std::error::Error 这个特性即可。 std::error::Error 在 Rust 的不同版本中曾经出现过多种定义，在目前的成熟版本中已经大道至简了。它的定义大致如下：
pub trait Error: Debug + Display {fn source(&self) -> Option<&(dyn Error + 'static)> {None}
}
3. Error 数据类型的最小实现
Error 特性就需要实现一个函数，而且已经有了默认实现。也就是说，最简单的错误类型实现可能只需要下面的代码即可：
#[derive(Debug)]
struct MyError {}impl Display for MyError {fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {write!(f, "error here!")}
}impl Error for MyError {}
impl Error for MyError {} 这行代码有用吗？答案是有用。它可以让 MyError 实现 source(&self) 函数。
4. Error 数据类型如何附加错误信息？
想给 Error 数据类型发加上错误信息怎么办？
很简单，添加一个错误信息属性即可。示例代码如下：
#[derive(Debug)]
struct MyError {message: String;
}impl MyError {fn new(message: &str) -> Self {MyError{message: message.to_string(),}}
}impl Display for MyError {fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {write!(f, message)}
}impl Error for MyError {}
5. 为什么 Rust 不提供一个通用的 Error 数据类型，让一些简单的程序不再编写自己的专用 Error 错误类型？
Rust 不直接提供一个通用的 Error 数据类型，而是采用了更为灵活和强大的错误处理机制，主要基于 trait（接口）的方式来实现错误处理，这是 Rust 设计中的一个核心原则：零成本抽象（Zero-cost abstractions）和不允许隐式转换。以下是一些主要原因：
-
类型安全：Rust 强调类型安全，每个错误都可能有其独特的上下文和属性。提供一个通用的
Error类型会失去这种类型安全性，因为所有的错误都会被当作同一类型处理，从而丢失了关于错误本质的具体信息。通过使用特定的错误类型，Rust 能够提供更准确的错误信息，这对于调试和错误处理非常重要。 -
灵活性：通过自定义错误类型，开发者可以根据需要为错误添加任意数量的字段和方法。这些字段和方法可以提供有关错误的额外信息（如错误代码、消息、堆栈跟踪等），从而提高了错误处理的灵活性和表达力。
-
错误链（Error Chaining）：Rust 通过
std::error::Errortrait 和std::fmt::Displaytrait 提供了错误链的功能。虽然这要求你定义自己的错误类型，但它允许你将多个错误连接成一个链，并在处理时逐一访问。这种机制在复杂系统中特别有用，因为它可以保持错误的上下文并允许进行更细致的错误分析。 -
零成本抽象：Rust 的设计哲学之一是“零成本抽象”，即使用高级语言特性（如泛型、trait 等）而不增加运行时开销。提供一个通用的
Error类型可能会引入隐式转换和额外的运行时开销，这与 Rust 的设计原则相悖。 -
可组合性：Rust 的错误处理系统是可组合的，意味着你可以轻松地将多个错误处理逻辑组合在一起。虽然这要求你定义自己的错误类型，但它提供了更大的灵活性和可重用性。例如，你可以创建一个通用的错误包装器（wrapper），用于包装不同类型的错误并添加额外的上下文。
-
文档和可读性：自定义错误类型有助于提高代码的可读性和可维护性。当你看到一个具体的错误类型时，你可以很容易地知道它代表什么类型的错误，而不需要查看该错误的文档或源代码。此外，自定义错误类型还可以包含有用的文档字符串，这些字符串提供了关于错误的额外信息。
尽管 Rust 不提供一个通用的 Error 类型，但它通过提供 std::error::Error trait 和相关机制来支持灵活且强大的错误处理。这些机制鼓励开发者编写类型安全、灵活且易于维护的代码。
6. 如何定义一个“完整的” Error 类型
下面给出标准库的一段示意性代码。
我们可以注意到，错误代码依赖 ErrorKind 枚举类型。定义自己的错误类型枚举，是自定义 Error 类型的关键。正因为有了这个枚举类型，收到错误的一方才能快速准确确定错误类型。换言之，宁愿不要 message 属性，也建议提供错误类型属性。
在 Rust 标准库中，std::io::Error 是一个用于表示 I/O 操作错误的类型。这个类型是由 Rust 标准库提供的，而不是由用户直接定义的。不过，我们可以根据 Rust 的错误处理机制和类型系统的特点，给出一个示意性的表示，以帮助你理解 std::io::Error 是如何被设计的。
请注意，实际的 std::io::Error 实现可能包含更多的细节和复杂性，包括与平台相关的错误代码、内部状态管理等。但以下是一个简化的示意性代码，用于说明 std::io::Error 可能的基本结构和一些关键特性：
// 假设的模块和类型定义，仅用于示意
mod io {// 定义一个枚举来表示不同类型的 I/O 错误#[non_exhaustive] // 标记枚举可能在未来版本中增加新的变体pub enum ErrorKind {NotFound,PermissionDenied,ConnectionRefused,// ... 其他可能的错误类型}// Error 是一个结构体，用于封装错误的具体信息#[derive(Debug, PartialEq)]pub struct Error {// 错误类型kind: ErrorKind,// 可能包含额外的错误信息或上下文message: String,// ... 可能还有其他字段，如错误码、源位置等}// 实现 std::error::Error trait，以便 Error 可以被用作错误类型impl std::error::Error for Error {fn source(&self) -> Option<&(dyn std::error::Error + 'static)> {// 如果 Error 封装了另一个错误，这里可以返回它// 在这个简化的例子中，我们假设没有封装其他错误None}}// 实现 std::fmt::Display trait，以便可以格式化打印错误信息impl std::fmt::Display for Error {fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {write!(f, "{}", self.message) // 简化处理，只打印消息}}// 可能还有其他方法和函数，如从 raw OS 错误码创建 Error 实例等// ...
}// 注意：上述代码是示意性的，并不是 std::io::Error 的实际实现
// 在真实的 Rust 标准库中，std::io::Error 会更复杂，并且会利用 Rust 的高级特性来提供更强大的功能
在 Rust 的真实 std::io 模块中，Error 类型实际上是一个更复杂的结构体或枚举，它可能包含与平台相关的错误码、错误消息的本地化支持、以及可能链接到源错误的 Source 链等。此外，std::io::Error 还实现了 std::error::Error 和 std::fmt::Display trait，以及可能的其他 trait，如 std::fmt::Debug，以支持错误处理和调试。
由于 Rust 标准库的实现可能会随着版本更新而变化，因此建议查看最新的 Rust 文档或标准库源代码以获取准确的信息。
)
