异常处理：try/except/finally 与自定义异常

引言

在前面的文章中，我们已经学习了函数的定义、作用域、可变参数、lambda、装饰器和递归。这些内容让我们能够组织复杂的计算逻辑，但一个真实的项目不仅需要”正常路径”的正确性，更需要对异常情况的妥善处理。当文件不存在、网络请求超时、用户输入非法时，程序应该如何反应？

Python 的异常处理机制设计哲学与许多静态类型语言不同：它推崇 EAFP（Easier to Ask Forgiveness than Permission，事后获取原谅比事前许可更容易），即先尝试操作，失败再捕获处理，而非在操作前做大量防御性检查（LBYL：Look Before You Leap）。这种哲学影响了 Python 的库设计和编码风格。

本文将系统讲解 Python 异常处理的完整机制，包括异常层次结构、try/except/else/finally 四段式、raise 抛出异常、自定义异常类、异常链式处理，以及实践中需要警惕的性能陷阱。

概念与原理

Python 异常处理的设计哲学

Python 的异常处理机制并非简单地将”错误”视为程序失败，而是将其视为控制流的一种形式。当异常被抛出时，Python 会沿着调用栈向上查找匹配的 except 块，这一过程称为”栈展开”（stack unwinding）。在展开过程中，Python 会依次执行每个帧的 finally 子句，确保资源被正确释放。

这种设计有一个重要含义：异常不是”坏事情”，而是”特殊路径”。一个编写良好的 Python 程序应当让异常只在真正异常的情况下发生，而 normal flow 应该走 try 块内的正常路径。这正是 EAFP 哲学的底层逻辑。

从实现层面看，Python 解释器在遇到 raise 语句时，会创建一个异常对象，然后沿着调用栈逐帧向上查找匹配的 except 块。如果没有找到匹配的 except，异常会继续向上传播直到到达解释器顶层，此时 Python 打印 traceback 并退出程序。如果在传播过程中遇到了 finally 块，解释器会先执行 finally 中的代码再继续传播。这一机制保证了无论错误发生在多深的调用栈中，资源清理代码都能被正确执行。

异常对象与异常层次

Python 中，所有异常都是 BaseException 的子类。异常本质上是一个对象，当错误发生时被”抛出”（raise），随后被”捕获”（catch）：

BaseException
├── SystemExit          # sys.exit() 触发
├── KeyboardInterrupt   # 用户按 Ctrl+C
├── GeneratorExit       # 生成器关闭时触发
└── Exception           # 所有普通异常的基类
    ├── ArithmeticError
    │   ├── ZeroDivisionError
    │   ├── OverflowError
    │   └── FloatingPointError
    ├── AssertionError
    ├── AttributeError
    ├── EOFError
    ├── ImportError
    │   ├── ModuleNotFoundError
    │   └── ZipImportError
    ├── LookupError
    │   ├── IndexError
    │   └── KeyError
    ├── MemoryError
    ├── NameError
    │   └── UnboundLocalError
    ├── OSError
    │   ├── FileNotFoundError
    │   ├── PermissionError
    │   ├── TimeoutError
    │   └── ...
    ├── RuntimeError
    │   ├── NotImplementedError
    │   └── RecursionError
    ├── TypeError
    ├── ValueError
    │   └── UnicodeError
    └── Warning

理解这个层次结构至关重要：捕获 `Exception` 会同时捕获其所有子类（`ValueError`、`TypeError` 等），但不会捕获 `SystemExit`、`KeyboardInterrupt` 和 `GeneratorExit`——这三个是 `BaseException` 的直接子类，设计意图是让它们不被常规异常处理拦截，从而保证程序可以被正常终止。

一个常见的误解是认为 `Exception` 能捕获所有错误。实际上，`BaseException` 才是所有异常的根类，`Exception` 只覆盖"普通异常"。在编写框架代码（如 Web 服务器中间件）时，如果需要捕获所有可能的异常包括键盘中断，才需要显式继承 `BaseException`——但这种情况极其罕见，绝大多数业务代码都应该以 `Exception` 为基类。

验证继承关系：

print(isinstance(ValueError(), Exception))       # True
print(isinstance(Exception(), BaseException))     # True
print(isinstance(ValueError(), BaseException))    # True
print(issubclass(ZeroDivisionError, Exception))   # True

EAFP 与 LBYL 的设计哲学

Python 社区普遍偏好 EAFP 风格：先尝试操作，用 try/except 处理失败情况。这与 Java 等语言的 LBYL 风格形成对比。以下是一个文件读取的对比：

# LBYL 风格（不推荐）
import os
if os.path.exists('config.json'):
    with open('config.json') as f:
        data = f.read()
else:
    data = '{}'

# EAFP 风格（推荐）
import json

try:
    with open('config.json') as f:
        data = json.load(f)
except FileNotFoundError:
    data = {}

EAFP 的优势在于：它避免了竞态条件（检查存在性和实际读取之间文件可能被删除），代码更简洁，且将正常逻辑和错误处理清晰分离。但 EAFP 有一个重要前提：异常应该是异常情况，而不是正常流程的一部分。

try/except/else/finally 四段式

Python 的异常处理由四个子句构成，它们的执行顺序有严格的语义：

try:
    # 可能抛出异常的代码
    result = delicate_operation()
except SomeError as e:
    # 仅当 SomeError 被抛出时执行
    handle_error(e)
else:
    # 仅当 try 块没有抛出任何异常时执行
    use_result(result)
finally:
    # 无论是否抛出异常都执行（包括 return/break/continue）
    cleanup()

各子句的执行规则：

• try 块：包含可能出错的代码。
• except 块：可以出现多次，每次捕获不同异常类型。如果省略，则所有异常都会向上传播。
• else 块：只有在 try 块没有抛出任何异常时才执行。这避免了将不应被捕获的代码放在 try 块中。
• finally 块：无论是否发生异常、是否执行了 return，都会执行。常用于释放资源（关闭文件、断开连接）。

验证各子句的执行顺序：

def test_else():
    try:
        result = 10 / 2
    except ZeroDivisionError:
        return 'error'
    else:
        return f'else branch: {result}'

print(test_else())  # else branch: 5.0

def test_finally():
    try:
        result = 10 / 2
    except ZeroDivisionError:
        return 'error'
    finally:
        print('finally always runs')
        return 'done'

print(test_finally())  # 先打印 finally，再返回 'done'

注意：finally 中的 return 会覆盖 try 或 else 中的返回值。在实际工程中，应避免在 finally 中 return，以免遮蔽异常信息。

操作与实现

捕获特定异常

最安全的做法是只捕获你预期会抛出的具体异常类型，而不是用裸 except: 捕获所有异常：

def parse_config(path: str) -> dict:
    import json
    try:
        with open(path) as f:
            return json.load(f)
    except FileNotFoundError:
        print(f'Config file not found: {path}')
        return {}
    except json.JSONDecodeError as e:
        print(f'Invalid JSON in {path}: {e}')
        return {}

这里分别处理了文件不存在和 JSON 格式错误两种情况，每种情况有不同的恢复策略。

多异常统一处理

当多个异常需要相同的处理逻辑时，可以使用元组形式：

def safe_divide(a: float, b: float) -> float:
    try:
        return a / b
    except (ZeroDivisionError, TypeError) as e:
        print(f'Cannot divide: {e}')
        return 0.0

print(safe_divide(10, 0))    # Cannot divide: division by zero → 0.0
print(safe_divide(10, 'a'))  # Cannot divide: unsupported operand type(s) → 0.0

异常对象的结构

每个异常对象都有几个关键属性：

• args：构造函数传入的参数元组。
• __cause__：显式链中的原始异常（通过 from 设置）。
• __context__：隐式链中的当前异常上下文。
• __traceback__：异常发生时的完整回溯信息，包含文件名、行号和调用栈。

try:
    int("not_a_number")
except ValueError as e:
    print(e.args)              # ("invalid literal for int()...",)
    print(e.__traceback__)     # <traceback object at ...>
    print(type(e.__traceback__).__name__)  # traceback

理解这些属性有助于编写更好的错误日志和异常恢复逻辑。__traceback__ 尤其重要——它将异常与发生位置绑定，使得 traceback.print_exception() 可以打印完整的调用栈，这是调试复杂错误的关键工具。

异常的上下文与链式传播

Python 3 引入了两个重要机制来追踪异常的完整上下文：__cause__ 和 __context__。

__cause__ 是显式链，通过 from 关键字建立：

try:
    open("config.json")
except FileNotFoundError as original:
    raise RuntimeError("Configuration unavailable") from original

__context__ 是隐式链，当在一个异常处理块中抛出新异常时自动建立：

try:
    try:
        int("not_a_number")
    except ValueError:
        raise TypeError("type error")  # 没有 from，建立隐式链
except TypeError as e:
    print(e.__cause__)       # None（没有显式 from）
    print(e.__context__)     # ValueError 实例

理解这两种链的区别对调试至关重要：显式链（__cause__）表达”这个错误是因为那个错误导致的”，隐式链（__context__）表达”这个错误在那个错误的处理过程中发生了”。

raise 抛出异常

使用 raise 语句主动抛出异常，可以附带错误信息：

def set_age(age: int) -> None:
    if not isinstance(age, int):
        raise TypeError(f'Expected int, got {type(age).__name__}')
    if age < 0 or age > 150:
        raise ValueError(f'Age must be 0-150, got {age}')
    print(f'Age set to {age}')

set_age(25)          # Age set to 25
set_age(-5)          # 抛出 ValueError

自定义异常类

自定义异常应继承自 Exception（而非 BaseException），并遵循项目的异常命名规范——以 Error 后缀结尾：

class DataProcessingError(Exception):
    """数据处理过程中的基础异常"""
    pass

class ValidationError(DataProcessingError):
    """数据校验失败"""
    pass

class NotFoundError(DataProcessingError):
    """数据未找到"""
    pass

继承层次使得上层异常可以同时捕获所有子异常：

try:
    raise ValidationError('Invalid input format')
except DataProcessingError as e:
    print(f'Caught: {type(e).__name__}: {e}')
    # 输出: Caught: ValidationError: Invalid input format

验证异常的多态性：

class AppError(Exception):
    pass

class ValidationError(AppError):
    pass

class NotFoundError(AppError):
    pass

# 捕获基类可以匹配所有子类
try:
    raise ValidationError('Invalid input')
except AppError as e:
    print(f'Caught as AppError: {type(e).__name__}, {e}')

try:
    raise NotFoundError('User not found')
except AppError as e:
    print(f'Caught as AppError: {type(e).__name__}, {e}')

from ... except 链式异常

Python 3 引入了异常链式机制，使用 from 关键字可以明确记录异常的原始原因：

def load_user(user_id: int) -> dict:
    try:
        # 模拟数据库查询
        result = int(user_id)  # 如果 user_id 不是数字会触发 ValueError
    except ValueError as original:
        raise TypeError(f'Invalid user ID type: {user_id}') from original

try:
    load_user('not_a_number')
except TypeError as e:
    print(f'Caught: {e}')
    print(f'Original cause: {e.__cause__}')
    print(f'Cause type: {type(e.__cause__).__name__}')

输出：

Caught: Invalid user ID type: not_a_number
Original cause: invalid literal for int() with base 10: 'not_a_number'
Cause type: ValueError

`e.__cause__` 保存了原始异常的引用，`traceback` 会同时展示两层栈信息，便于调试。如果不使用 `from`，Python 会将前一个异常存储为 `e.__context__`（隐式链），但在调试时不如显式链清晰。

### EAFP 的适用边界

虽然 EAFP 被广泛推荐，但它并非万能。关键在于判断"异常是否罕见"。以下基准测试展示了不同场景下的性能差异：

import timeit

def eafp_divide(numbers):
    results = []
    for n in numbers:
        try:
            results.append(100 / n)
        except ZeroDivisionError:
            results.append(0)
    return results

def lbyl_divide(numbers):
    results = []
    for n in numbers:
        if n == 0:
            results.append(0)
        else:
            results.append(100 / n)
    return results

# 正常情况（无零值）
numbers_normal = [1, 2, 3, 4, 5] * 2000
t1 = timeit.timeit(lambda: eafp_divide(numbers_normal), number=100)
t2 = timeit.timeit(lambda: lbyl_divide(numbers_normal), number=100)
print(f"Normal - EAFP: {t1:.4f}s, LBYL: {t2:.4f}s")

# 频繁异常（大量零值）
numbers_frequent = [1, 2, 0, 4, 5] * 2000
t3 = timeit.timeit(lambda: eafp_divide(numbers_frequent), number=100)
t4 = timeit.timeit(lambda: lbyl_divide(numbers_frequent), number=100)
print(f"Frequent - EAFP: {t3:.4f}s, LBYL: {t4:.4f}s")

当异常罕见时，EAFP 更快（因为没有 if 检查的开销）；当异常频繁时，LBYL 更快（因为避免了对比异常对象的成本）。在实际工程中，大多数网络 I/O、文件操作的异常确实是罕见的，因此 EAFP 通常更优。但像字典键查找这种高频操作，dict.get() 配合 LBYL 风格的 if key in d 往往更清晰高效。

异常的性能开销与最佳实践

异常本身在 Python 中是有开销的操作。创建异常对象、填充栈帧信息、回溯查找 handler 都需要时间。基准测试可以直观展示这种差异：

import timeit

def check_with_if():
    for _ in range(10000):
        x = -1
        if x < 0:
            pass
        else:
            pass

def check_with_exception():
    for _ in range(10000):
        try:
            x = -1
            if x < 0:
                raise ValueError('negative')
        except ValueError:
            pass

t1 = timeit.timeit(check_with_if, number=100)
t2 = timeit.timeit(check_with_exception, number=100)
print(f'if check: {t1:.4f}s')
print(f'try/except: {t2:.4f}s')
print(f'Ratio: {t2/t1:.1f}x')

在频繁发生异常的场景中，try/except 比 if 检查慢约 5 倍。但当异常是罕见情况时，EAFP 通常比 LBYL 更快——因为没有异常时 try 块的开销极小，而 if 检查每次都执行。

核心原则：异常应用于”异常情况”，而不应作为正常流程控制手段。以下是一个典型反模式：

# 反模式：用异常控制正常查找流程
class Found(Exception):
    def __init__(self, index):
        self.index = index
        super().__init__()

def bad_find(items, target):
    for i, item in enumerate(items):
        try:
            if item == target:
                raise Found(i)
        except Found as e:
            return e.index
    return -1

# 正确做法：使用 return
def good_find(items, target):
    for i, item in enumerate(items):
        if item == target:
            return i
    return -1

用异常控制流程不仅可读性差，而且在异常频繁发生时性能显著下降。上面的基准测试显示，当异常成为正常路径的一部分时，EAFP 反而比 LBYL 更慢。

易错点与陷阱

陷阱一：裸 except: 捕获一切

裸 except: 等价于 except Exception:，会捕获几乎所有运行时错误，包括你本意不想捕获的 KeyboardInterrupt（Ctrl+C）和 SystemExit。正确做法是始终指定异常类型：

# 错误：捕获一切，包括 Ctrl+C
try:
    do_something()
except:
    handle_error()

# 正确：只捕获预期的异常
try:
    do_something()
except (ValueError, TypeError) as e:
    handle_error(e)

如果你确实需要捕获所有异常（例如在日志装饰器中），应使用 except Exception as e 而非裸 except:，这样可以保留 KeyboardInterrupt 和 SystemExit 的正常传播。

陷阱二：在 except 中静默吞掉异常

try:
    process_data()
except Exception:
    pass  # 异常被静默吞掉，调试时难以发现

这种做法会导致错误信息完全丢失，给调试带来极大困难。至少应该记录日志：

import logging

logger = logging.getLogger(__name__)

try:
    process_data()
except Exception as e:
    logger.error(f'Data processing failed: {e}', exc_info=True)
    raise  # 重新抛出，让调用方知道发生了错误

陷阱三：finally 中的 return 遮蔽异常

def risky_operation() -> int:
    try:
        return 1 / 0
    finally:
        return 42  # 这个 return 会遮蔽上面的 ZeroDivisionError！

print(risky_operation())  # 输出 42，异常被静默吞掉

finally 块中的 return 语句会无条件覆盖 try 或 except 中的返回值，包括异常。这是极其危险的陷阱，应严格避免在 finally 中使用 return。finally 的唯一职责是清理资源。

陷阱四：异常处理块中包含不该被捕获的代码

try:
    data = load_config()      # 可能抛出 FileNotFoundError
    result = parse(data)      # parse 中的 Bug 也会被 FileNotFoundError 的 except 捕获！
except FileNotFoundError:
    data = get_default_config()

如果 parse() 函数内部抛出 KeyError，它会被 except FileNotFoundError 忽略并向上继续传播，但如果写成 except Exception，则会错误地将 parse() 的内部错误当作”配置文件未找到”来处理。解决方式是将不需要被捕获的代码移出 try 块：

data = load_config()  # 不在 try 块中
try:
    result = parse(data)
except FileNotFoundError:
    data = get_default_config()
    result = parse(data)

或使用 else 子句将正常逻辑与异常处理分离：

try:
    data = load_config()
except FileNotFoundError:
    data = get_default_config()
else:
    result = parse(data)  # 只在没有异常时执行

实际工程中的异常处理模式

在真实项目中，异常处理往往遵循几个经典模式：

模式一：重试机制。网络请求、数据库操作等暂时性失败应当重试：

import time

def retry_with_backoff(fn, max_retries=3, base_delay=1.0):
    for attempt in range(max_retries):
        try:
            return fn()
        except (ConnectionError, TimeoutError) as e:
            if attempt == max_retries - 1:
                raise
            delay = base_delay * (2 ** attempt)
            print(f"Attempt {attempt + 1} failed: {e}, retrying in {delay}s")
            time.sleep(delay)

模式二：统一入口的错误转换。Web 框架通常在中间件层统一捕获异常并转换为 HTTP 响应：

from fastapi import FastAPI, HTTPException

app = FastAPI()

@app.get("/items/{item_id}")
async def read_item(item_id: int):
    item = get_item(item_id)
    if item is None:
        raise HTTPException(status_code=404, detail="Item not found")
    return item

这里将业务异常（数据不存在）转换为标准的 HTTP 状态码，由框架统一处理。

模式三：异常工厂函数。当同一个操作可能产生多种相关错误时，使用工厂函数统一管理：

def validate_email(email: str) -> str:
    if not email:
        raise ValueError("Email cannot be empty")
    if "@" not in email:
        raise ValueError(f"Invalid email format: {email}")
    return email

这些模式的核心思想是一致的：异常应该携带足够的语义信息，让调用方能做出有意义的恢复决策。

小结

Python 的异常处理机制是其优雅性的核心体现之一。通过 try/except/else/finally 四段式，开发者可以将正常逻辑与错误处理清晰分离；通过继承 Exception 自定义异常类，可以构建语义明确的错误层次；通过 from 链式异常，可以保留完整的错误上下文。

关键要点：异常应用于异常情况，不应作为正常流程控制手段；始终捕获具体的异常类型而非裸 except:；避免在 finally 中使用 return；将不应该被捕获的代码移出 try 块。遵循这些原则，异常处理将成为你代码中可靠的保障，而非隐患的来源。

练习与思考题

1. 编写一个函数 safe_int_convert(s: str) -> int | None，尝试将字符串转为整数，转换失败时返回 None 而非抛出异常。比较 EAFP 和 LBYL 两种写法，分析各自的优劣。
2. 设计一个异常层次：AppError（基类）、DatabaseError(AppError)、NotFoundError(DatabaseError)、ConnectionError(DatabaseError)。编写一个模拟数据库操作的函数，当查询失败时抛出 NotFoundError，网络断开时抛出 ConnectionError，并用统一的 except AppError 捕获。
3. 分析以下代码的问题，指出会吞掉哪些异常，以及如何修复：

   try:
       config = load_config()
       result = process(config)
       save(result)
   except:
       pass

4. 解释 from e 和隐式 __context__ 的区别，并在什么场景下应优先使用显式链式异常。