返回错误代码
这是最古老的策略之一——如果一个函数可能会出错，它可以简单地返回一个错误代码——通常是负数或者null。例如，C 语言中经常使用：
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 }
Go 采用的方式简单而有效，会将错误传递到调用方。但是，我觉得它会造成很多重复，而且影响到了实际的业务逻辑。不过，我写的 Go 还不够多，不知道这种印象以后会不会改观！😅
异常
异常可能是最常用的错误处理模式。try/catch/finally 方法相当有效，而且使用简单。异常在上世纪 90 年代到 2000 年间非常流行，被许多语言所采用（例如 Java、C＃ 和 Python）。
与错误处理相比，异常具有以下优点：
- 它们自然地区分了“快乐路径”和错误处理路径
- 它们会自动从调用堆栈中冒泡出来
- 你不会忘记处理错误！
然而，它们也有一些缺点：需要一些特定的运行时支持，通常会带来相当大的性能开销。
此外，更重要的是，它们具有“深远”的影响——某些代码可能会抛出异常，但被调用堆栈中非常远的异常处理程序捕获，这会影响代码的可读性。
此外，仅凭查看函数的签名，无法确定它是否会抛出异常。
C++ 试图通过throws 关键字来解决这个问题，但它很少被使用，因此在 C++ 17 中已被弃用 ，并在 C++ 20 中被删除。此后，它一直试图引入noexcept 关键字，但我较少写现代 C++，不知道它的流行程度。
（译者注：throws 关键字很少使用，因为使用过于繁琐，需要在函数签名中指定抛出的异常类型，并且这种方法不能处理运行时发生的异常，有因为“未知异常”而导致程序退出的风险）
Java 曾试图使用“受检的异常（checked exceptions）”，即你必须将异常声明为函数签名的一部分——但是这种方法被认为是失败的，因此像 Spring 这种现代框架只使用“运行时异常”，而有些 JVM 语言（如 Kotlin）则完全抛弃了这个概念。这造成的结果是，你根本无法确定一个函数是否会抛出什么异常，最终只得到了一片混乱。
（译者注：Spring 不使用“受检的异常”，因为这需要在函数签名及调用函数中显式处理，会使得代码过于冗长而且造成不必要的耦合。使用“运行时异常”，代码间的依赖性降低了，也便于重构，但也造成了“异常源头”的混乱）
回调函数
另一种方法是在 JavaScript 领域非常常见的方法——使用回调，回调函数会在一个函数成功或失败时调用。这通常会与异步编程结合使用，其中 I/O 操作在后台进行，不会阻塞执行流。
例如，Node.JS 的 I/O 函数通常加上一个回调函数，后者使用两个参数（error，result），例如：
const fs = require('fs'); fs.readFile('some_file.txt', (err, result) => { if (err) { console.error(err); return; } console.log(result); });
但是，这种方法经常会导致所谓的“回调地狱”问题，因为一个回调可能需要调用其它的异步 I/O，这可能又需要更多的回调，最终导致混乱且难以跟踪的代码。
现代的 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); } }
使用回调进行错误处理是一种值得了解的重要模式，不仅仅在 JavaScript 中如此，人们在 C 语言中也使用了很多年。但是，它现在已经不太常见了，你很可能会用的是某种形式的async/await。
函数式语言的 Result
我最后想要讨论的一种模式起源于函数式语言，比如 Haskell，但是由于 Rust 的流行，它已经变得非常主流了。
它的创意是提供一个Result类型，例如：
enum Result<S, E> { Ok(S), Err(E) }
这是一个具有两种结果的类型，一种表示成功，另一种表示失败。返回结果的函数要么返回一个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 语句。
（译者注：函数式编程认为函数的输入和输出应该是纯粹的，不应该有任何副作用或状态变化。monad 是一个函数式编程的概念，它通过隔离副作用和状态来提高代码的可读性和可维护性，并允许组合多个操作来构建更复杂的操作）
根据你使用的编程语言和项目，你可能主要或仅仅使用其中一种错误处理的模式。
不过，我最喜欢的还是 Result 模式。当然，不仅是函数式语言采用了它，例如，在我的雇主 lastminute.com 中，我们在 Kotlin 中使用了 Arrow 库，它包含一个受 Haskell 强烈影响的类型Either。我有计划写一篇关于它的文章，最后感谢你阅读这篇文章，敬请保持关注😊。
