错误处理：异常好于状态码

错误处理有不同的方式。

JavaScript 和 Python 是抛出异常， Rust 语言是变相抛出异常。

C 语言和 Go 语言则是返回一个错误值，你必须判断该值是否为 -1 或空值。

我一直想知道，哪一种方式更好？

前不久，我读到一篇多年前的文章，明确提出抛出异常好于返回状态码。他的理由很有说服力，文章好像还没有中译，我就翻译出来了。

异常与返回状态码

作者：内德·巴切尔德（Ned Batchelder）

原文网址：nedbatchelder.com

在软件中，错误处理有两种方式：抛出异常（throwing exceptions）和返回状态码（returning status codes）。

几乎所有人都认为异常是更好的处理方式，但有些人仍然更喜欢返回状态码。本文解释为什么异常是更好的选择。

一、代码干净

异常可以让你在大部分代码中省去错误处理步骤。它会自动通过不捕捉异常的层，向上传递。你因此可以编写完全没有错误处理逻辑的代码，这有助于保持代码的简洁易读。

让我们比较一下，编写同一个简单函数的两种方法。

先是返回状态码。

STATUS DoSomething(int a, int b)
{
    STATUS st;
    st = DoThing1(a);
    if (st != SGOOD) return st;
    st = DoThing2(b);
    if (st != SGOOD) return st;
    return SGOOD;
}

上面示例中，必须判断DoThing1(a)和DoThing2(b)的返回值是否正常，才能进行下一步。

如果是抛出异常，就不需要中间的错误判断了。

void DoSomething(int a, int b)
{
    DoThing1(a);
    DoThing2(b);
}

这只是最简单的情况，如果遇到复杂的场景，状态码带来的噪音会更严重，异常则可以保持代码的整洁。

二、有意义的返回值

状态码会占用宝贵的返回值，你不得不增加代码，判断返回值是否正确。

有些函数本来只需要返回一个正常值，现在不得不增加返回错误的情况。随着时间的推移，代码量不断增长，函数变得越来越大，返回值也越来越复杂。

比如，很多函数的返回值是有重载的："如果失败，则返回 NULL"，或者失败返回 -1。结果就是每次调用这个方法，都需要检查返回值是否是 NULL 或 -1。如果函数后来增加新的错误返回值，则必须更新所有调用点。

如果是抛出异常，那么函数就总是成功的情况下才返回，所有的错误处理也可以简化放在一个地方。

三、更丰富的错误信息

状态码通常是一个整数，能够传递的信息相当有限。假设错误是找不到文件，那么是哪一个文件呢？状态码无法传递那么多信息。

返回状态码的时候，最好记录一条错误消息，放在专门的错误日志里面，调用者可以从中获取详细信息。

异常完全不同，它是类的实例，因此可以携带大量信息。由于异常可以被子类化，不同的异常可以携带不同的数据，从而形成非常丰富的错误消息体系。

四、可以处理隐式代码

某些函数无法返回状态码。例如，构造函数就没有显式的返回值，因此无法返回状态码。还有一些函数（比如析构函数）甚至无法直接调用，更不用说返回值了。

这些没有返回值的函数，如果不使用异常处理，你不得不想出其他方法来给出错误信息，或者假装这些函数不会失败。简单的函数或许可以做到无故障，但代码量会不断增长，失败的可能性也随之增加。如果没有办法表达失败，系统只会变得更加容易出错，也更加难以捉摸。

五、错误的可见性

考虑一下，如果程序员疏忽了，没有写错误处理代码，会发生什么情况？

如果返回的状态码没有经过检查，错误就不会被发现，代码将继续执行，就像操作成功一样。代码稍后可能会失败，但这可能是许多步操作之后的事情，你如何将问题追溯到最初错误发生的地方？

相反的，如果异常未被立刻捕获，它就会在调用栈中向上传递，要么到达更高的 catch 块，要么到达顶层，交给操作系统处理，操作系统通常会把错误呈现给用户。这对程序是不好的，但错误至少是可见的。你会看到异常，能够判断出它抛出的位置，以及它应该被捕获的位置，从而修复代码。

这里不讨论错误未能报出的情况，这种情况无论是返回状态码还是抛出异常，都没用。

所以，对于报出的错误没有被处理，可以归结为两种情况：一种是返回的状态码会隐藏问题，另一种是抛出异常会导致错误可见。你会选择哪一种？

六、反驳

著名程序员 Joel Spolsky 认为，返回状态码更好，因为他认为异常是一种糟糕得多的 goto。

"异常在源代码中是不可见的。阅读代码块时，无法知道哪些异常可能被抛出，以及从哪里抛出。这意味着即使仔细检查代码，也无法发现潜在的错误。"

"异常为一个函数创建了太多可能的出口。要编写正确的代码，你必须考虑每一条可能的代码路径。每次调用一个可能抛出异常的函数，但没有立即捕获异常时，函数可能突然终止，或者出现其他你没有想到的代码路径。"

这些话听起来似乎很有道理，但如果改为返回状态码，你就必须显式地检查函数每一个可能的返回点。所以，你是用显式的复杂性换取了隐式的复杂性。这也有缺点，显式的复杂性会让你只见树木不见森林，代码会因此变得杂乱无章。

当面临这种显式复杂性时，程序员会写得不胜其烦，最后要么用自定义的方法隐藏错误处理，要么索性省略错误处理。

前者隐藏错误处理，只会将显式处理重新变为隐式处理，并且不如原始的 Try 方法方便和功能齐全。后者省略错误处理更糟糕，程序员假设某种错误不会发生，从而埋下风险。

七、总结

返回状态码很难用，有些地方根本无法使用。它会劫持返回值。程序员很容易不去写错误处理代码，从而在系统中造成无声的故障。

异常优于状态码。只要你的编程语言提供了异常处理工具，请使用它们。

（完）