作者:Andrea Bergia
译者:豌豆花下猫@Python猫
转载请保留作者及译者信息
错误处理是编程的一个基本要素。除非你写的是“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
}
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。我有计划写一篇关于它的文章,最后感谢你阅读这篇文章,敬请保持关注😊。
译注:还有一篇《Musings about error handling mechanisms in programming languages》文章,同样分析了不同编程语言在错误处理时的方案。它还介绍了 Zig 编程语言的做法、Go 语言的 defer 关键字等内容,可以丰富大家对这个话题的理解,推荐一读。