读前：这一章要回答什么

第 4～9 章一直在讲怎样把模块做深。这一章用同样的眼光看异常：一个类会抛出的异常属于它的接口，而且是特别"重"的那部分，因为异常会穿过好几层调用栈，牵连的不只是直接调用者。所以异常越多，模块越浅。

它也是好几条线索的交汇点。第 6 章 6.8 节说要消除特殊情况，而异常正是特殊情况代码最主要的来源之一；本章的"屏蔽"是第 8 章"把复杂性往下拉"的一个实例；"聚合"则又一次说明了通用机制的好处。10.9 节"别做过头"预告了第 21 章的主题：判断什么重要。

这一章最反直觉的地方，是它反对"能检测的错误越多越好"这种防御式本能。读的时候注意作者的论证并不是"错误不重要"，而是处理异常的地方越少越好，而最好的办法是让一部分"错误"根本不存在。

核心观点

为什么异常处理格外昂贵

遇到异常，代码只有两条路：要么想办法继续往前做（重发、从副本恢复），要么中止并往上报。前者会引出新的异常：重发的包其实没丢，只是迟到了，对端就收到了重复的包；后者得先把做了一半的状态恢复一致，再交给上层，而上层又面临同样的二选一。书中把这叫作处理异常的过程中产生的次生异常，它们往往比原来的异常更隐蔽。

语言的异常语法也在添乱。书中用一段 Java 反序列化代码说明，光是 try/catch 的样板就比正常逻辑还长（10.1 节）。下面是同样问题的 C++ 版本：

// 从快照文件恢复内存索引
try {
    File f(path);                          // 可能抛 IoError（不存在、无权限）
    Header h = readHeader(f);              // 可能抛 FormatError、IoError
    for (uint32_t i = 0; i < h.count; ++i)
        index_.insert(readEntry(f));       // 可能抛 FormatError、IoError
} catch (const FormatError& e) {
    // ……
} catch (const IoError& e) {
    // 是打开失败、读文件头失败，还是读到一半失败？到这里已经分不清了，
    // 而这三种情况下 index_ 的状态各不相同：空的、空的、填了一半。
}

一个大 try 块让人看不出每个异常从哪里来，也看不出出错时状态被破坏到了什么程度。反过来给每一行单独包 try，出错位置清楚了，正常流程却被切得支离破碎，相同的处理代码还会在几个 catch 里重复出现。两种写法都不好，根源在于需要处理的地方太多。

更麻烦的是，异常处理代码很少被执行。I/O 错误在测试环境里很难造出来，于是处理代码里的 bug 可以潜伏很久，等到真正需要它的那天才发现它不工作。作者有一句很喜欢的话：

code that hasn't been executed doesn't work— 第 10.1 节

书中引用了 OSDI 2014 年的一项研究（Yuan 等）：在分布式数据密集型系统里，超过 90% 的灾难性故障是由错误处理不当造成的。本站补充：那篇论文的标题就叫《简单的测试就能防止大多数严重故障》，很多出事的处理代码一眼就能看出问题（比如空的 catch、只写了一行 TODO），只是从来没有被测试覆盖过。

所以本章的策略很朴素：

Throwing exceptions is easy; handling them is hard.— 第 10.2 节

既然难的是处理，那就让需要处理的地方越少越好。作者给出了四种技术，其中把错误定义掉是最好的办法。它们的区别可以用一个问题概括：处理器放在哪里？

交互：数一数要写几个 catch

下面是一个小型文本协议服务器的调用关系：分发器把命令交给 5 个处理函数，每个处理函数会调用解析参数、存储层、内存分配、回写响应等下层函数，每个调用都可能出现某种异常。一开始采用最直接的写法：哪里可能出错，就在哪里处理。按书中的顺序依次打开四种技术，观察处理位置的数量怎么变化，以及它们被挪到了哪里。最后试试那个黄色的选项。

计数规则：屏蔽、聚合、崩溃都不是让处理器消失，而是把许多处理器合成一个，所以它们各算 1 处；只有定义掉才真正是 0。19 处、几个异常种类都是本站为演示设定的规模。

四种技术，按书中的顺序

① 把错误定义掉

书中的三个例子用的是同一招。Tcl 的 unset 在变量不存在时报错，作者事后称这是自己设计 Tcl 时最大的错误之一：unset 最常见的用途是清理一个可能只做了一半的操作留下的临时变量，调用者根本不确定哪些变量存在，只好每次都包一层 catch。把定义从"删除变量"改成"确保变量不存在"，错误就消失了（10.3 节）。Unix 允许删除一个正被打开的文件：名字立刻从目录里消失，数据等最后一个使用者关闭后才释放，删除方和使用方都不会遇到错误；Windows 的做法则是拒绝删除（10.4 节）。Java 的 substring 越界抛异常，如果定义成"取落在这个区间里的那些字符"，越界就不再是错误（10.5 节）。

下面是一个服务端常见的原创例子：连接关闭时取消它的空闲超时定时器。

// 取消定时器。id 不存在（从未创建、已经触发、已经取消）时抛 NoSuchTimer。
void TimerWheel::cancel(TimerId id);

void Connection::close() {
    try {
        timers_.cancel(idleTimer_);
    } catch (const NoSuchTimer&) {
        // 超时回调可能刚好已经触发了，也可能 close() 被调用了两次
    }
    ::close(fd_);
}

// 确保 id 对应的回调以后不会再被调用。若它已经触发或已被取消，什么也不做。
// 返回这次调用是否真的阻止了一次触发（极少数调用者关心）。
bool TimerWheel::cancel(TimerId id);

void Connection::close() {
    timers_.cancel(idleTimer_);
    ::close(fd_);
}

可以把这一招整理成几种常见的"改定义"句式（本站整理）：

② 屏蔽：在底层就地处理

有些异常无法定义掉，但可以在很低的层次处理掉，让上层根本看不到。TCP 在内部重传丢掉的包，应用只看到一个可靠的字节流。书中还举了一个更有争议的例子：NFS 服务器无响应时，客户端会一直重试，应用就挂在那里，控制台上打印"服务器没有响应，仍在重试"。作者认为这比报错更好：应用拿到错误也没什么可做的，要么自己重试（同样挂住），要么层层中止，最后用户的整个工作环境都垮掉，服务器恢复后还得把所有程序重启一遍（10.6 节）。

一个原创例子：分布式键值存储的客户端库。请求发到了非 leader 节点，或者 leader 刚刚换了，这对调用者来说毫无意义，客户端库可以自己处理：

// 读取 key。请求发到非 leader 节点时，节点会回复 NotLeader 并附上它所知道的 leader，
// 客户端自动切换过去重发；调用者看不到这种情况。
// 只有到 deadline 仍得不到答复时才返回 Unavailable。
Result<std::string> KvClient::get(std::string_view key, Deadline d) {
    for (;;) {
        Reply r = rpc(leaderHint_, GetRequest{key}, d);
        if (r.ok())        return r.value();
        if (r.notLeader()) { leaderHint_ = r.leader(); continue; }
        if (r.timedOut())  {
            if (d.expired()) return Unavailable{};
            leaderHint_ = nextNode();
            continue;
        }
        return r.error();   // 其他错误（比如权限不足）照常上报
    }
}

这一个循环替所有调用者处理掉了"找错节点"和"节点暂时无响应"两种情况，KvClient 的接口变小了，功能却变多了，模块更深。注意两个细节：读操作是幂等的，所以重发安全；如果是写操作，重发可能造成重复写入（10.1 节说的次生异常），需要给请求带上唯一 id 让服务端去重。另外它仍然保留了 deadline：屏蔽的是调用者不需要知道的事，"一直连不上"调用者是需要知道的。

③ 聚合：在高处用一个处理器接住一批

书中 10.7 节的例子来自学生写的 Web 服务器：每个处理 URL 的方法都要取参数，很多学生在每次取参数的地方各包一个 catch，所有 catch 干的都是同一件事。更好的做法是让异常一路传到顶层的分发方法，在那里只写一个处理器。下面是同样思路的原创例子，注意"改之前"用的是返回值，并没有 throw，但按本章的广义定义，它照样是一处处异常处理：

Response handleCreateOrder(const HttpRequest& req, const User& user) {
    auto sku = req.json().getString("sku");
    if (!sku) return Response::badRequest("missing field 'sku'");
    auto qty = req.json().getInt("qty");
    if (!qty) return Response::badRequest("missing field 'qty'");
    if (*qty <= 0) return Response::badRequest("'qty' must be positive");
    if (!user.can(Permission::PlaceOrder)) return Response::forbidden("no permission");
    return Response::created(orders_.create(user.id(), *sku, *qty));
}
// handleCancelOrder、handleUpdateAddress……几十个处理函数都是这个样子

// 处理一个请求时，任何地方都可以抛 RequestError 来中止这个请求。
// message 在抛出处生成，分发器把它放进错误响应。
struct RequestError : std::runtime_error {
    RequestError(int status, std::string message);
    int status;
};

Response handleCreateOrder(const HttpRequest& req, const User& user) {
    user.require(Permission::PlaceOrder);                    // 不满足时抛 403
    auto sku = req.json().requireString("sku");              // 缺失时抛 400
    auto qty = req.json().requireInt("qty", {.min = 1});     // 缺失或越界时抛 400
    return Response::created(orders_.create(user.id(), sku, qty));
}

Response Dispatcher::dispatch(const HttpRequest& req) {
    try {
        return route(req)(req, authenticate(req));
    } catch (const RequestError& e) {
        return Response::error(e.status, e.what());   // 唯一的处理器
    }
}

书中把这总结成一个通用模式：系统处理一连串请求时，定义一种"中止当前请求"的异常，在请求循环顶部捕获，清理状态后继续处理下一个请求。作者特别提醒，这类异常要和"整个系统都完了"的致命异常明确区分。上面的分发器只捕获 RequestError，不用 catch (...)，原因就在这里。

错误提升（error promotion）是聚合的另一种形式。作者的 RAMCloud 存储系统本来就必须能从整台服务器崩溃中恢复，于是发现单个对象损坏时，它不去单独修复那个对象，而是直接让服务器崩溃，复用那套恢复机制。这样少写了一套恢复代码，而且崩溃恢复被执行得更频繁，其中的 bug 更容易被发现。代价是恢复成本变大，所以只适合罕见的错误：不能每丢一个网络包就让服务器崩溃（10.7 节）。本站补充：系统领域有一篇著名的短文《Crash-Only Software》（Candea 与 Fox，2003），主张让"崩溃后重启"成为唯一的停机和恢复路径；Erlang 社区的"let it crash"也是类似的思路。

④ 直接崩溃

有些错误难以处理、很少发生，处理它们的代码多半永远不会被执行。这时最简单的做法是打印诊断信息后退出。书中的例子是内存耗尽：C 的 malloc 返回 NULL 要求每个调用者都检查，而真有可以释放的内存，程序早就该释放了，所以作者主张用一个包装函数代替 malloc，分配失败就带着信息退出；C++ 的 new 抛 bad_alloc，捕获它也没什么意义，处理代码自己多半还要分配内存（10.8 节）。内部数据结构不一致也属于这一类，它通常意味着 bug：

// 内部不变量被破坏说明有 bug：打印位置和原因后立即终止，不尝试恢复。
[[noreturn]] void fatal(const char* file, int line, const char* expr, const char* msg);
#define KV_CHECK(cond, msg) \
    do { if (!(cond)) ::kv::fatal(__FILE__, __LINE__, #cond, (msg)); } while (0)

KV_CHECK(entry.offset + entry.len <= segment.size(), "index entry points past segment end");

能不能崩溃要看应用。对多数程序来说，读写已打开文件时的磁盘硬错误、打不开网络套接字，都可以带着清楚的信息退出；但对一个副本存储系统，遇到 I/O 错误就退出是不可接受的，从副本恢复数据正是它向用户提供的核心价值。

边界与反方

练一练

下面三道题来自训练场：一道识红旗、一道 A/B 对比、一道"给每种异常选技术"的书写题。本章共 23 题。

再加一道，取材于读者讨论组（对应上面"边界与反方"里的"讨论组"一栏）：

动手：项目任务

读完本章去做 minikv 的任务 m06。minikv 的存储层把很多正常情况当作错误抛出（比如删除一个不存在的键、读取一个越界的区间），服务端的命令处理函数于是各自带着一长串 catch，同样的错误响应写了很多遍。启动时也有问题：进程崩溃留下的末尾半条记录和日志中间真正的损坏走同一条报错路径，前者让程序拒绝启动，使用者只能手工截断文件。你要做的是：先找出哪些错误可以通过改定义消失，再把剩下的请求级错误聚合到命令分发处；把末尾半条记录在最底层屏蔽掉；为真正不可恢复的中间损坏选择直接崩溃，并给出清楚的说明。注意这个任务会有意改变 DEL 和 GETRANGE 的外部行为，相应的测试要跟着改（任务页里说明了哪些），其余测试保持全绿。

cd project/minikv && make test

自测题

小结与读后一句话

• 异常（包括特殊返回值）对复杂性的贡献不成比例：处理代码难写、会制造次生异常、很少执行所以很难保证正确。
• 抛出容易、处理难，所以目标是减少必须处理异常的地方。
• 定义掉（改语义）优先；定义不掉的，按位置选屏蔽（底层就地处理）或聚合（高处一个处理器，包括错误提升）；罕见且无法恢复的直接崩溃（看应用）。
• 屏蔽和聚合都是把处理器挪到能接住最多异常的地方；只有定义掉能让处理器真正消失。
• 别做过头：调用者需要的信息必须暴露，哪怕接口因此变复杂。

本章里最有力的几招，往往都不是第一个想到的设计：unset 的作者一开始就设计错了。第 11 章讲的正是怎样逼自己在动手之前想出第二个、第三个方案。

读后一句话：用你自己的话写下这一章最重要的一个观点，最好结合你写过的某段错误处理代码。