错误处理是编程中不可或缺的一部分，即使是简单的“Hello World”程序也需要考虑如何处理潜在的错误。
本文将深入探讨四种常见的错误处理模式，帮助你选择最适合你的编程风格和项目需求的方案。
这是最古老、最直接的错误处理方式。当函数可能出错时，它返回一个特定的错误代码，通常是一个负数或null。
例如，在C语言中，我们经常使用：
FILE* fp = fopen("file.txt" , "w");if (!fp) { // 发生了错误}
这种方法简单易懂，执行效率高，因为它只需要进行标准的函数调用和返回值操作，不需要额外的运行时支持或内存分配。
然而，它也存在一些缺点：
● 易于遗漏错误处理
用户可能忘记检查函数的返回值，例如，C语言中的 printf 函数可能会出错，但很少有人会检查它的返回值。
● 处理多个错误繁琐
当代码需要处理多个不同的错误时，传递错误信息到调用堆栈会变得很麻烦。
● 返回值和错误信息冲突
除非你的编程语言支持多个返回值，否则如果必须返回一个有效值或一个错误，就很麻烦。这导致C和C++中的许多函数必须通过指针来传递存储了“成功”返回值的地址空间，再由函数填充，类似于：
my_struct *success_result;int error_code = my_function(&success_result);if (!error_code) { // can use success_result}
为了解决这些问题，一些编程语言引入了多返回值机制，例如Go语言：
user, err = FindUser(username)if err != nil { return err}
这种方法简单高效，但可能导致代码中出现大量的重复错误处理逻辑，影响实际业务逻辑的清晰度。
异常可能是最常用的错误处理模式。
try/catch/finally 机制简单易用，被许多语言（如Java、C#、Python）广泛采用。
异常相较于返回错误代码，具有以下优点：
● 清晰的错误处理路径
自然地区分了正常执行路径和错误处理路径。
● 自动错误传播
异常会自动从调用堆栈中冒泡出来，无需手动传递错误信息。
● 避免遗漏错误处理
编译器会强制要求处理所有可能抛出的异常。
然而，异常也存在一些缺点：
● 性能开销
异常机制需要额外的运行时支持，通常会带来性能开销。
● 代码可读性下降
异常处理程序可能位于调用堆栈中很远的位置，影响代码可读性。
● 函数签名不透明
无法从函数签名中判断它是否会抛出异常。
一些语言试图通过 throws 关键字或 noexcept 关键字来解决这些问题，但它们的使用率并不高。
Java曾经尝试使用“受检异常”，要求在函数签名中声明可能抛出的异常，但这种方法被认为是失败的，因为会导致代码过于冗长和耦合。
现代框架（如Spring）倾向于使用“运行时异常”，而一些JVM语言（如Kotlin）则完全放弃了“受检异常”。
回调函数是JavaScript领域中常见的错误处理方式，它在函数成功或失败时被调用。
这种方法通常与异步编程结合使用，例如Node.JS的I/O函数：
const fs = require('fs');fs.readFile('some_file.txt', (err, result) => { if (err) { console.error(err); return; } console.log(result);});
回调函数可以有效地处理异步操作中的错误，但它也容易导致“回调地狱”问题，因为嵌套的回调会使代码难以阅读和维护。
现代的JavaScript版本试图通过引入 promise 来提升代码的可读性：
fetch("https://example.com/profile", { method: "POST", // or 'PUT'}) .then(response => response.json()) .then(data => data['some_key']) .catch(error => console.error("Error:", error));
promise 模式并不是最终方案，JavaScript 最后采用了由C推广开的 async/await 模式，它使异步I/O看起来非常像带有经典异常的同步代码：
async function fetchData() { try { const response = await fetch("my-url"); if (!response.ok) { throw new Error("Network response was not OK"); } return response.json()['some_property']; } catch (error) { console.error("There has been a problem with your fetch operation:", error); }}
尽管 promise 和 async/await 提高了代码可读性，但回调函数仍然是处理异步操作中错误的重要模式，尤其是在C语言等传统语言中。
这种模式起源于函数式语言，如Haskell，并因Rust语言的流行而变得主流。
它的核心思想是提供一个 Result 类型，例如：
enum Result<S, E> { Ok(S), Err(E)}
Result 类型包含两种结果：Ok 表示成功，Err 表示失败。
函数返回 Result 类型，要么返回包含数据的 Ok 对象，要么返回包含错误信息的 Err 对象。
调用者可以通过模式匹配来处理这两种情况。
为了在调用堆栈中传播错误，我们可以使用以下代码：
let result = match my_fallible_function() { Err(e) => return Err(e), Ok(some_data) => some_data,};
Rust语言专门引入了一个操作符 ? 来简化这种模式：
let result = my_fallible_function()?; // 注意有个"?"号
这种方法的优点是它使错误处理显式且类型安全，编译器会确保处理所有可能的结果。
Result 通常是一个monad，它允许将可能失败的函数组合起来，而无需使用 try/catch 块或嵌套的 if 语句。
本文介绍了四种常见的错误处理模式，每种模式都有其优劣。选择哪种模式取决于你的编程语言、项目需求和个人偏好。
希望本文能够帮助你更好地理解各种错误处理模式，并选择最适合你的方案，写出更加优雅和健壮的代码。
小狮博客
