异常 II：防御式编程、测试与调试

0. 本讲导读

到目前为止，你写的每一段代码都是假定一切顺利写出来的：divide(a, b) 假定 b 不是 0，lst[i] 假定 i 没越界，next(it) 假定迭代器还有东西。上一讲的迭代器和生成器把这个假设推到了极致——一个耗尽的迭代器再取值就会抛 StopIteration，而 for 循环之所以能正常结束，恰恰是因为它在内部接住了这个异常。

换句话说：异常不是「程序坏了」的信号，它是 Python 的一种正常控制流机制。 第 1 讲的「异常 I」教了你怎么读报错，这一讲要教你三件更主动的事。

这一讲和前十讲的气质不太一样：它讲的不是某个新的语言特性，而是怎么写出别人（和三个月后的你）能看懂、能维护、坏了能修的程序。这些东西在期末不会以「写出 try 的语法」的形式来考，但它决定了你后面做 Ants、Scheme 解释器这些大项目时，是两小时搞定还是两天卡死。

再往后一讲就是期中复习，考试范围包含到复习课为止的全部内容——所以本讲的 try／raise／常见异常表都在范围内。

1. 复习：异常是什么，以及为什么要让程序「大声地失败」

课上给的定义只有一句话：

这句话里有两个词值得抠。

第一个是「执行过程中」。这把异常和另一类错误划清了界限。SyntaxError 是在 Python 还没开始执行你的程序时、把源码解析成可执行形式的阶段就报出来的——所以文件里只要有一处语法错，整个文件一行都不会跑。而 ZeroDivisionError 这种是执行到那一行才发生的，前面的代码已经跑完了，副作用（比如 print）也已经发生了。这个区别在调试时非常实用：如果你在文件开头加了一句 print("start") 却连它都没打出来，那基本可以断定是语法错误。

第二个是「抛出」。异常不是「返回」，它不沿着正常的返回路径走。当一个异常被抛出时，当前正在执行的语句立刻中断，当前这一帧被丢弃，控制权交还给调用它的那一帧——但不是以「函数返回了一个值」的方式回去的，而是带着「我这里出事了」的状态回去。如果调用者也没管，就继续往上弹。这个过程叫栈展开（stack unwinding），下一节会画出来。

为什么不能「什么都不做」

课上在讲 raise 时抛了一个问题：「为什么要抛异常？我们不能就什么都不做吗？」 这个问题值得认真回答，因为它是整讲的思想基础。

假设你写一个求平方根的函数，遇到负数输入时「什么都不做」——就让它自然地算下去：

>>> def square_root(x):
...     return x ** 0.5
...
>>> square_root(16)
4.0
>>> square_root(-4)
(1.2246467991473532e-16+2j)

它没有报错。它返回了一个复数——这是 Python 对 (-4) ** 0.5 的合法解释。如果你的程序后面拿这个值去比大小，就会撞上：

>>> square_root(-4) > 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '>' not supported between instances of 'complex' and 'int'

看看这个报错发生在哪里：它发生在比大小那一行，而真正的病根在 square_root(-4) 那次调用。这两处可能隔着几十行、几个函数、甚至几个文件。你要花的调试时间，全部浪费在「从症状倒推回病因」上。

更糟的情况是它连报错都不报，只是算出一个错误但看起来正常的数字，然后你的成绩单上多了一个 D。

反过来说，这条原则也解释了为什么裸写 except: 是危险的：它把一切异常都吞掉，等于系统性地关掉了所有「大声失败」的机制，让程序回到悄悄算错的状态。课上原话是「remember, we don't want to fail silently」。

2. 读懂 traceback：一次完整的调试演示

课上的调试演示用的是 11-debug.py，这段代码来自 John DeNero 教授的调试视频。它只有九行，却塞进了三个层次完全不同的 bug。我们把它当成一个完整的案例走一遍——这一节是本讲最值得慢慢读的部分。

def f(x):
    return g(x - 1)

def g(y):
    return abs(h(y) - h(1 /* y)

def h(z):
    z * z

print(f(12))
print(f(1))

第一层：连一行都跑不起来

直接运行：

$ python3 11-debug.py
  File "/tmp/11-debug.py", line 10
    return abs(h(y) - h(1 /* y)
                           ^
SyntaxError: invalid syntax

>>> x = (1 + 2
... y = 3
  File "<stdin>", line 2
    y = 3
    ^^^^^
SyntaxError: invalid syntax

第二层：跑起来了，但类型不对

修好语法后再跑：

$ python3 11-debug.py
Traceback (most recent call last):
  File "/tmp/11-debug.py", line 10, in <module>
    print(f(12))
  File "/tmp/11-debug.py", line 2, in f
    return g(x - 1)
  File "/tmp/11-debug.py", line 5, in g
    return abs(h(y) - h(1 / y))
TypeError: unsupported operand type(s) for -: 'NoneType' and 'NoneType'

这是本讲最需要练熟的技能：把这一坨东西读出信息来。

剩下几行 File 是怎么走到案发现场的路径。从上往下是调用发生的顺序：全局帧（<module>）调用了 f，f 调用了 g，g 里出的事。「most recent call last」这句话就是这个意思：最近的调用排在最后。

第三层：类型也对了，但输入本身有问题

把 h 修好之后：

$ python3 11-debug.py
120.99173553719008
Traceback (most recent call last):
  File "/tmp/11-debug.py", line 11, in <module>
    print(f(1))
  File "/tmp/11-debug.py", line 2, in f
    return g(x - 1)
  File "/tmp/11-debug.py", line 5, in g
    return abs(h(y) - h(1 / y))
ZeroDivisionError: division by zero

f(12) 成功了，打出 120.99173553719008。算一下就知道它是对的：f(12) → g(11) → abs(11² − (1/11)²) = abs(121 − 0.008264…) = 120.9917…。

f(1) 却炸了。f(1) → g(1 - 1) = g(0) → 1 / 0。

异常抛出时，栈上到底发生了什么

这是本讲对「求值过程」这个母题的回答。以 f(1) 为例，把帧一层层画出来。

正常展开阶段——每次调用用户定义的函数就新建一帧：

抛出瞬间的栈           →  展开中           →  展开中        →  到顶
─────────────────         ───────────         ─────────        ────────
f2: g   y=0  ← 抛出       (丢弃)              (丢弃)           (丢弃)
f1: f   x=1               f1: f   x=1  ← 到我  (丢弃)          (丢弃)
Global                    Global              Global ← 到我     打印 traceback
                                                                程序终止

沿途记录（这就是 traceback 的内容，从下往上是弹出顺序）：
    line 11, in <module>  print(f(1))
    line  2, in f         return g(x - 1)
    line  5, in g         return abs(h(y) - h(1 / y))
ZeroDivisionError: division by zero

3. Python 常见异常速查：每一个都配真实报错

课上给了三页表格，列出十三个常见异常。光背「什么意思」没用——真正有用的是看到这个异常名，能立刻反推出「我大概干了什么蠢事」。下面这张表把课上的定义和真实报错并排放在一起，报错信息都是在 Python 3.10 上实际跑出来的。

最容易混淆的一组：TypeError vs ValueError vs IndexError

这三个的边界，靠一句话就能划清：先问类型对不对，再问值合不合适，最后问有没有更专门的异常。

UnboundLocalError：这个值得单独讲

它是这十三个里唯一一个需要动用「作用域」知识才能理解的。看这段代码：

def f():
    if False:
        x = 1
    x = x + 1
    return x

f()

Traceback (most recent call last):
  File "/tmp/ub.py", line 6, in <module>
    f()
  File "/tmp/ub.py", line 4, in f
    x = x + 1
UnboundLocalError: local variable 'x' referenced before assignment

count = 0

def bump():
    count = count + 1     # UnboundLocalError
    return count

RecursionError：递归没收住时到底发生了什么

把阶乘的 base case 去掉：

def fact(n):
    return n * fact(n - 1)

fact(5)

Traceback (most recent call last):
  File "/tmp/rec.py", line 3, in <module>
    fact(5)
  File "/tmp/rec.py", line 2, in fact
    return n * fact(n - 1)
  File "/tmp/rec.py", line 2, in fact
    return n * fact(n - 1)
  ... （中间省略大量重复）
  File "/tmp/rec.py", line 2, in fact
    return n * fact(n - 1)
  [Previous line repeated 996 more times]
RecursionError: maximum recursion depth exceeded

[Previous line repeated 996 more times] 这一行是 RecursionError 的招牌。看到超长且重复的 traceback，先去检查：base case 写了吗？递归调用真的在往 base case 靠近吗？ 第二个问题更隐蔽——fact(n) 里如果不小心写成 fact(n) 而不是 fact(n - 1)，问题参数永远不变，同样跑不到底。

4. 防御式编程：assert、type hints 与 raise

防御式编程（defensive programming）指的是一整套「预防 bug」的技术。第 1 讲已经见过其中两样，这一讲补上第三样，也是最有表达力的一样。

assert：把假设写成代码

语法是 assert <condition>, <message>。如果 <condition> 是 falsy，就抛出 AssertionError，消息是 <message>；是 truthy 就当这行不存在。

>>> def fact(n):
...     assert n >= 0, 'n must be non-negative'
...     return 1 if n == 0 else n * fact(n - 1)
...
>>> fact(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in fact
AssertionError: n must be non-negative

注意 assert 用的是真假性（truthiness），不是「必须等于 True」。assert lst 在 lst 是空列表时会失败——这正是想要的效果。

assert (n >= 0, 'n must be non-negative')      # 永远不会失败！

type hints：写给人和工具看的注释

类型提示把「这个参数应该是什么类型」这件本来只存在于文档字符串里（甚至只存在于作者脑子里）的信息，写成了代码的一部分：

def add(a: int, b: int) -> int:
    return a + b

学了容器之后，类型提示可以写得更精确：

def to_string(lst: list[str]) -> str:
    total = ""
    for s in lst:
        total += s
    return total

list[str] 的意思是「一个元素全是 str 的 list」。同理还有 dict[str, int]、tuple[int, int] 等等。

>>> def add(a: int, b: int) -> int:
...     return a + b
...
>>> add('hello', ' world')
'hello world'

那类型提示的价值在哪？在静态分析工具（static analysis tool）——不执行代码、只分析源码文本的工具。课上提到的两个概念要分清：

课上顺带提了一句：大多数主流 linter 都有 VS Code 扩展，装上之后写代码时问题会直接标在编辑器里。

raise：抛出比 AssertionError 更有信息量的异常

assert 有一个局限：它只能抛 AssertionError。而 AssertionError 这个名字本身不携带任何信息——它只说明「有个断言挂了」。如果你想告诉调用者「问题出在值上」还是「问题出在类型上」，就得自己挑一个异常类抛。

语法：raise <exception>，其中 <exception> 可以是一个异常类，也可以是一个异常实例（想带消息时就用实例）。

raise TypeError
raise ValueError('n must be a positive integer')

>>> def square_root(x: float) -> float:
...     if x < 0:
...         raise ValueError('x must be non-negative')
...     return x ** 0.5
...
>>> square_root(16)
4.0
>>> square_root(-4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in square_root
ValueError: x must be non-negative

对照第 1 节那个不做检查的版本（它悄悄返回了 (1.2246467991473532e-16+2j)），差别一目了然：现在 traceback 直接指向 square_root 的第 3 行，消息就是人话，调用者不需要理解这个函数的内部实现就知道自己错在哪。

assert 还是 raise？

5. 分解与代码风格：让 bug 无处藏身

这一节讲的东西没有语法可背，但它回答了一个很实际的问题：为什么有的代码你一眼就能看出 bug，有的代码盯半小时也看不出来？

问题分解（decomposition）

在 61A 里，你通常实现的是单个函数或者小项目。而真实世界的代码库可能有成百上千个文件、上百万行代码。课上的原话是：因此，把问题分解成子问题、把不同部分的关注点分开，以避免重复，是至关重要的。最基本的手段就是写辅助函数（helper function）。

怎么判断一个函数该拆了？课上提到 linter 能做圈复杂度分析（cyclomatic complexity analysis）：给出一个数字，衡量函数有多「复杂」，从而告诉你什么时候该把东西拆出去或减少重复。

课上的演示是 ruff check complexity.py，例子长这样（来自 Ruff 官方文档的 complex-structure 规则）：

def normalize_status(status):
    if status == "new":
        return "queued"
    if status == "queued":
        return "running"
    if status == "running":
        return "done"
    if status == "failed":
        return "retry"
    if status == "cancelled":
        return "closed"
    return "unknown"

这个函数完全正确，但它的问题是：每加一个状态就要加两行 if，而这些 if 的形状一模一样——重复的结构在暗示数据被写死进了控制流。改成把数据从代码里抽出来：

STATUS_TRANSITIONS = {
    "new": "queued",
    "queued": "running",
    "running": "done",
    "failed": "retry",
    "cancelled": "closed",
}


def normalize_status(status):
    return STATUS_TRANSITIONS.get(status, "unknown")

函数体从 11 行变成 1 行，圈复杂度从 6 降到 1。更重要的是：新增一个状态现在只需要改数据，不需要碰逻辑。 第 8 讲学的字典，用处正在于此：把「查表」这件事从控制流里搬进数据里。

代码风格（code style）

课上引用了一个具体的定义（Řechtáčková 等，2025）：代码风格缺陷（code style defect）是指「一段功能正确、但可以写得更清晰、更优雅、更符合惯例的代码」。

注意「功能正确」这四个字：风格问题不是 bug。那为什么要在意？课上给的理由很直接：代码不只是写给机器看的，也是写给同行（和未来的自己）看的。可读的代码更好维护、更好调试。

Linter 和 formatter 能帮上忙。课上的演示是 ruff format format.py——把一个故意写得很丑的文件（乱七八糟的空格、把一整个字典写在一行上、不一致的引号）自动排版成规范格式。

6. 测试驱动开发与测试覆盖率

测试驱动开发（test-driven development，TDD）是一种软件工程实践，课上把它拆成了五步：

顺序是这一整套方法的全部要点：测试写在代码之前。为什么这个顺序重要？

课上给了两条写测试的理由：

• 把软件验证这件事自动化，尤其对于多人同时开发的大型互联代码库。
• 在边界情况真正出事之前把它们抓出来，并确保它们被处理了。

测试的四种类型

这四类的区别是「一次测多大一块」。它们的取舍很直白：单元测试跑得快、出错时能精确定位到某个函数，但测不出「各部分接在一起时会不会打架」；端到端测试最接近真实使用，但一旦挂了，你只知道「系统坏了」，得自己去翻是哪一环。所以实践中是金字塔形：大量单元测试 + 少量集成测试 + 极少量 E2E。

测试框架

大多数编程语言都有测试框架（testing framework），让写测试和跑测试变得容易。课上提了两个：

doctest 失败时长这样，格式非常好读：

$ python3 -m doctest bad.py
**********************************************************************
File "/tmp/bad.py", line 3, in bad.add
Failed example:
    add(1, 2)
Expected:
    4
Got:
    3
**********************************************************************
1 items had failures:
   1 of   1 in bad.add
***Test Failed*** 1 failures.

Expected 和 Got 这两行，就是调试流程第 3 步「期望值和实际值差在哪」的直接答案。 很多同学看到红字就慌了直接改代码——先把这两行读完，往往差异本身就把 bug 指出来了（差 1？符号反了？类型不对？返回了 None？）。

测试覆盖率

测试覆盖率（test coverage）：跑完一整套测试后，源代码中被执行到的行数占总行数的百分比。

课上对它的评价相当克制，几条都值得记住：

def sign_label(n):
    label = "non-negative"
    if n < 0:
        label = "negative"
    return label

7. 测试实战一：把覆盖率提到 100%，然后发现它没用

课上的第一个练习用的是 count_vowel_occurrences.py。函数本身不难，难的是怎么看待它的测试。

def count_vowel_occurrences(text: str, vowel: str) -> int:
    """
    Counts the number of times a specific vowel appears in the given text.
    The search is case-insensitive.
    ...
    Raises:
    ValueError: If the 'vowel' argument is not a single character or
                not a valid vowel (a, e, i, o, u).

    Doctests:
    -- Standard Cases --
    >>> count_vowel_occurrences("hello world", "o")
    2

    -- Edge Case: Vowel Not Present --
    >>> count_vowel_occurrences("myth", "y")
    Traceback (most recent call last):
        ...
    ValueError: 'y' is not a valid vowel.
    """
    # Guard clause 1: Ensure vowel is a single character
    if len(vowel) != 1:
        raise ValueError("Vowel must be a single character.")

    # Guard clause 2: Ensure the character is actually a vowel
    if vowel.lower() not in "aeiou":
        raise ValueError(f"'{vowel}' is not a valid vowel.")

    # Standardize inputs to lowercase for case-insensitivity
    text_lower = text.lower()
    vowel_lower = vowel.lower()

    # Count and return
    return text_lower.count(vowel_lower)

先注意这个函数示范了前面几节的全部要点：类型提示写明契约、两个守卫子句在最开头挡住非法输入、raise ValueError 带具体消息、docstring 里连「会抛什么异常」都写清楚了。这就是防御式编程写出来的样子。

doctest 怎么测「会抛异常」

这是很多人第一次见的写法：

>>> count_vowel_occurrences("myth", "y")
Traceback (most recent call last):
    ...
ValueError: 'y' is not a valid vowel.

doctest 对 traceback 有特殊处理：只要以 Traceback (most recent call last): 开头，中间那些 File ... 行可以用 ... 一笔带过，doctest 只比对最后那一行「异常类型: 消息」。 这个设计很合理——traceback 里的文件路径和行号会随着代码移动而变化，不该被写死进测试。

# 错误写法 1：只写异常行，没有 Traceback 开头
>>> count_vowel_occurrences("myth", "y")
ValueError: 'y' is not a valid vowel.

# 错误写法 2：消息写得不完全一致（少了句号）
>>> count_vowel_occurrences("myth", "y")
Traceback (most recent call last):
    ...
ValueError: 'y' is not a valid vowel

练习本身：一个 doctest 达成 100% 覆盖率

课上让你先跑覆盖率报告（uv run pytest --doctest-modules --cov=count_vowel_occurrences --cov-report=html count_vowel_occurrences.py，然后打开 htmlcov/index.html），根据结果补一个 doctest 让覆盖率到 100%。

>>> count_vowel_occurrences("hello", "ou")
Traceback (most recent call last):
    ...
ValueError: Vowel must be a single character.

挑战题：100% 覆盖率，然后呢

课上紧接着说：「即使你用一个 doctest 就能达到 100% 覆盖率，这些测试其实并没有全面覆盖这个函数的行为。」 这就是上一节那个 sign_label 例子的现实版。官方解答里补的 doctest 是这些（我把它们按测试意图分了组）：

"Apples are awesome" 数出 3 是最值得算一遍的： 小写化后是 "apples are awesome"，其中 a 出现在 apples、are、awesome 三处开头，正好 3 个。

8. 测试实战二：三个失败的测试，三种不同的 bug

第二个练习给了一个成绩分析工具 src/grade_analytics.py 和一套 pytest 测试 tests/test_grade_analytics.py，跑起来有三个测试失败。任务是根据测试输出反推 bug 并修好。这是本讲「调试流程」的完整实战。

源码里有五个函数，前四个是单元测试的对象，最后一个 generate_grade_report 是把前面几个串起来的集成函数：

def calculate_average(grades: list) -> float:
    """Returns 0.0 if the list is empty."""
    return round(sum(grades) / len(grades), 2)


def get_range_extremes(grades: list) -> tuple:
    if not grades:
        return (None, None)
    return (max(grades), min(grades))


def map_score_to_letter(score: float) -> str:
    if score >= 85:
        return "A"
    elif score >= 80:
        return "B"
    elif score >= 70:
        return "C"
    elif score >= 60:
        return "D"
    else:
        return "F"


def apply_curved_bonus(grades: list, bonus_points: float) -> list:
    curved_grades = []
    for grade in grades:
        new_grade = grade + bonus_points
        if new_grade > 100:
            new_grade = 100
        curved_grades.append(new_grade)
    return curved_grades


def generate_grade_report(student_data: dict, bonus: float = 0.0) -> dict:
    report = {}
    for student, scores in student_data.items():
        if not scores:
            report[student] = "F"
            continue
        avg_score = calculate_average(scores)
        report[student] = map_score_to_letter(avg_score)
    return report

Bug 1：docstring 说了，代码没做

失败的测试是：

def test_calculate_average_empty():
    """Test calculate_average handles empty lists gracefully without throwing ZeroDivisionError."""
    assert calculate_average([]) == 0.0

def calculate_average(grades: list) -> float:
    if not grades:      # FIX
        return 0.0
    return round(sum(grades) / len(grades), 2)

用 if not grades 而不是 if len(grades) == 0：空列表是 falsy，这是 Python 惯例写法，和同一个文件里 get_range_extremes 的写法保持一致。顺带注意：get_range_extremes 早就正确处理了空列表——同一份代码里两个函数对同一个边界的处理不一致，本身就是「这里有 bug」的强烈信号。

Bug 2：边界值差了 5 分

这个测试用了 pytest 的参数化（parametrize），一行 @pytest.mark.parametrize 把 8 组输入输出变成 8 个独立的测试：

@pytest.mark.parametrize("score, expected_letter", [
    (95, "A"), (90, "A"), (85, "B"), (80, "B"),
    (72, "C"), (60, "D"), (55, "F"), (0, "F")
])
def test_map_score_to_letter_boundaries(score, expected_letter):
    assert map_score_to_letter(score) == expected_letter

    if score >= 90:     # FIX
        return "A"

Bug 3：参数收下了，但从来没用

这是三个里最难发现的，因为代码本身没有任何一行是错的。

def test_generate_grade_report_with_curve():
    class_data = {
        "Jordan": [78, 78],     # Average = 78 -> C raw
        "Taylor": [55, 58]      # Average = 56.5 -> F raw
    }
    # Giving a 3-point curve will push Jordan to an 81 (B) and Taylor to 59.5 (F)
    expected_output = {"Jordan": "B", "Taylor": "F"}
    assert generate_grade_report(class_data, bonus=3.0) == expected_output

    for student, scores in student_data.items():
        if not scores:
            report[student] = "F"
            continue

        # FIX: 1. Apply curve if applicable
        if bonus > 0:
            curved_scores = apply_curved_bonus(scores, bonus)
        else:
            curved_scores = scores

        # 2. Calculate the average score
        avg_score = calculate_average(curved_scores)

        # 3. Map average score to letter grade
        report[student] = map_score_to_letter(avg_score)

验证：把修好的版本代进四个集成测试

Taylor 那一行值得多看一眼：59.5 < 60，所以还是 F，差 0.5 分。这就是为什么测试作者在注释里写下了 Taylor to 59.5 (F)——他刻意挑了一个「加了分但还是不够」的例子，用来检验加分逻辑没有被过度实现（比如误写成加 3 分再向上取整）。

9. try 语句：优雅地接住异常

前面所有内容都在教你怎么让程序正确地失败。这一节相反：怎么让程序在遇到可预期的坏情况时，仍然走完流程。

try:
    <try suite>
except <exception> as <name>:    # 可选，可以有多个
    <except suite>
else:                            # 可选
    <else suite>
finally:                         # 可选
    <finally suite>

课上给了两条注记：

• Note 1：最少需要 try 配 except，或者 try 配 finally。
• Note 2：如果只写 except: 而不指定异常类，它会接住任何异常。这很危险（记住，我们不想悄悄失败），所以最佳实践是永远写明。

四个 suite 各自什么时候执行

这是本节唯一需要精确记忆的东西。

课上的例子把这四种情况全串起来了：

def safe_divide(numerator, denominator):
    try:
        result = numerator / denominator
    except ZeroDivisionError:
        result = 'Undefined'
    else:
        print(f"The result of the division is: {result}")
    finally:
        print("Cleanup")
    return result

>>> 1 / 0
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    1 / 0
    ~~^~~
ZeroDivisionError: division by zero
>>> safe_divide(1, 0)
Cleanup
'Undefined'
>>> safe_divide(4, 2)
The result of the division is: 2.0
Cleanup
2.0

逐调用推演

为什么要有 else？把它并进 try 不行吗

能跑，但语义变了。如果把 print(...) 直接写在 try 里：

try:
    result = numerator / denominator
    print(f"The result of the division is: {result}")   # 挪进来了
except ZeroDivisionError:
    result = 'Undefined'

现在这个 try 同时保护着两条语句。如果 print 那一行因为某种原因抛出了 ZeroDivisionError（听起来不可能，但换成别的异常类型就完全可能），它也会被这个 except 接住，而你以为接住的是除法的错。

用 as 拿到异常对象

except ZeroDivisionError as e 会把异常对象绑定到 e。异常是对象，可以被检查：

>>> try:
...     1 / 0
... except ZeroDivisionError as e:
...     print(type(e).__name__)
...     print(e)
...     print(repr(e))
...     print(e.args)
...
ZeroDivisionError
division by zero
ZeroDivisionError('division by zero')
('division by zero',)

print(e) 打出的就是消息文本（也就是 traceback 最后那一行冒号之后的部分）。这在写日志或者给用户提示时很有用。

多个 except 的匹配顺序

except 子句是从上到下依次尝试匹配的，第一个匹配上的胜出，剩下的全部跳过——和 if/elif 链完全一样。而且匹配用的是子类关系：except Exception 能接住几乎所有异常，因为它们都是 Exception 的子类。

>>> try:
...     int('x')
... except Exception as e:
...     print('generic caught first:', type(e).__name__)
... except ValueError:
...     print('never')
...
generic caught first: ValueError

finally 的一个陷阱

>>> def g():
...     try:
...         return 1
...     finally:
...         return 2
...
>>> g()
2

try 里的 return 1 已经准备好返回值 1 了，但在真正返回之前必须先执行 finally——而 finally 里的 return 2 把它顶掉了。同理，如果 finally 里 return，连正在传播的异常都会被丢弃。所以 finally 里不要写 return，它只该做清理（关文件、释放锁、打日志）。

回到起点：for 循环其实一直在用 try

上一讲讲迭代器时说过，for 循环遇到 StopIteration 就正常结束。现在你有能力理解那句话的真正含义了——for x in it: ... 大致等价于：

it = iter(iterable)
while True:
    try:
        x = next(it)
    except StopIteration:
        break
    <循环体>

10. 调试方法：从「盯着代码看」到一套可重复的流程

顺带一个冷知识：「bug」这个词并不是计算机时代才有的。课上引的维基百科说，用 bug 指代缺陷至少从 1870 年代起就是工程行话，远早于电子计算机和软件。1947 年前后，Grace Hopper 在哈佛研究 Mark II 和 Mark III 时，操作员把 Mark II 的一个故障追查到了一只卡在继电器里的飞蛾；他们把飞蛾取出来贴在日志本上，注明「第一个真正找到 bug 的案例」。

五步流程

课上给的通用调试流程，和前面几节的实战完全对应：

课上还专门补了一句：这一讲有意不涉及 AI 辅助编程工具，可能会在之后的特别专题讲。相应地，在讲期中复习建议时也提醒过：用大模型学习要小心，它们可能会产生幻觉、给出超纲或不正确的信息；把它们当成「换个说法解释概念」或「生成练习题」的工具是可以的，但必须自己核对正确性。

进阶调试手段

课上顺带交代了这条技能线往后怎么走：CS 61B 学 IntelliJ 调试器（Java），CS 61C、161、162 学 gdb（C 语言）。「在断点处暂停、检查当前状态」这个心智模型是通用的，换语言只是换按钮。

print 调试实战：make_acronym

课上最后一个练习：读源码、跑 pytest、用 print 调试找出并修复 bug。

def make_acronym(phrase: str) -> str:
    """
    Converts a given phrase into an uppercase acronym.
    Words can be separated by one or more spaces.
    """
    words = phrase.split(" ")
    acronym = ""
    for i in range(len(words)):
        current_word = words[i]
        first_letter = current_word[0]
        acronym += first_letter
    return acronym

def test_make_acronym_simple():
    assert make_acronym("central processing unit") == 'CPU'

def test_make_acronym_whitespace():
    assert make_acronym("  user   interface  ") == 'UI'

def test_make_acronym_long():
    assert make_acronym("Hyper  Text Markup Language") == 'HTML'

def test_make_acronym_empty():
    assert make_acronym("") == ''

怎么用 print 找出来？ 在最可疑的地方打印中间量。经验法则是：打印「循环变量」和「你以为它是什么的那个东西」。

def make_acronym(phrase: str) -> str:
    words = phrase.split(" ")
    print('DEBUG words =', words)              # ← 加这一行
    acronym = ""
    for i in range(len(words)):
        current_word = words[i]
        print('DEBUG i =', i, 'word =', repr(current_word))   # ← 和这一行
        first_letter = current_word[0]
        acronym += first_letter
    return acronym

DEBUG words = ['', '', 'user', '', '', 'interface', '', '']
DEBUG i = 0 word = ''
Traceback (most recent call last):
  ...
IndexError: string index out of range

第一行就把真相打出来了。 你以为 words 是 ['user', 'interface']，实际它有 8 个元素，一半是空串。

修复

def make_acronym(phrase: str) -> str:
    # FIX 1: .split() 不带参数会按任意长度的空白切分，并丢掉空串
    words = phrase.split()
    acronym = ""
    for i in range(len(words)):
        current_word = words[i]
        first_letter = current_word[0]
        acronym += first_letter
    # FIX 2: 整个缩写转成大写
    return acronym.upper()

验证修复

最后一行值得注意：[] 让 range(len(words)) 变成 range(0)，循环体一次都不执行，acronym 保持初值 ""，"".upper() 还是 ""。空输入这个边界是被 split() 顺手解决的，不需要额外的 if。 这是选对工具的红利。

11. 本讲小结

异常机制速查

四种「函数结束」方式的对比

读 traceback 的四步

测试与工具

12. 动手练习

练习 1：这段代码会打印什么

def risky(n):
    try:
        print('A')
        result = 10 / n
        print('B')
    except ZeroDivisionError:
        print('C')
        result = -1
    else:
        print('D')
    finally:
        print('E')
    return result

print(risky(2))
print(risky(0))

A
B
D
E
5.0
A
C
E
-1

练习 2：挑异常类型

下面每一句会抛出什么异常？先自己想，再对答案。

(a)  {'a': 1, 'b': 2}['c']
(b)  [10, 20, 30][3]
(c)  int('3.14')
(d)  'abc' + 5
(e)  len(42)
(f)  print(undefind_variable)
(g)  next(iter(''))

练习 3：给函数加防线

下面这个函数计算列表的平均值，但它有两个没被处理的坏情况。请用本讲学的技术加上防线，并说明你为什么选了那个异常类型。

def average(nums):
    return sum(nums) / len(nums)

def average(nums: list) -> float:
    """返回 nums 的算术平均值。

    >>> average([1, 2, 3])
    2.0
    >>> average([])
    Traceback (most recent call last):
        ...
    ValueError: cannot average an empty sequence
    """
    if len(nums) == 0:
        raise ValueError('cannot average an empty sequence')
    for x in nums:
        if not isinstance(x, (int, float)):
            raise TypeError(f'all elements must be numbers, got {x!r}')
    return sum(nums) / len(nums)

练习 4：为什么这个测试通过了却没意义

def letter_grade(score):
    if score >= 90:
        return 'A'
    elif score >= 80:
        return 'B'
    else:
        return 'F'


def test_letter_grade():
    assert letter_grade(95) == 'A'
    assert letter_grade(85) == 'B'
    assert letter_grade(50) == 'F'

这三个断言让 letter_grade 的每一行都被执行过，覆盖率 100%。但如果有人把 score >= 90 手滑写成 score >= 91，测试还会通过吗？该补哪些用例？

练习 5：栈展开的顺序

def a():
    print('a start')
    b()
    print('a end')

def b():
    print('b start')
    try:
        c()
    except ValueError:
        print('b caught it')
    print('b end')

def c():
    print('c start')
    raise ValueError('boom')
    print('c end')

a()

打印顺序是什么？如果把 b 里的 except ValueError 改成 except TypeError，又会怎样？

a start
b start
c start
b caught it
b end
a end

a start
b start
c start
Traceback (most recent call last):
  File "...", line 20, in <module>
    a()
  File "...", line 3, in a
    b()
  File "...", line 9, in b
    c()
  File "...", line 16, in c
    raise ValueError('boom')
ValueError: boom