Python 异常处理机制和异常链怎么理解？

简化版

Python 用 try/except/else/finally 处理异常，except 捕获异常，else 在没有异常时执行，finally 无论是否异常都会执行。异常链通过 raise ... from ... 保留原始异常上下文，方便排查根因。

详细版

基本结构：

try:
    result = risky()
except ValueError as exc:
    handle(exc)
else:
    use(result)
finally:
    cleanup()

含义：

try：放可能出错的代码；
except：捕获并处理指定异常；
else：只有没有异常时才执行；
finally：无论是否异常都执行，常用于清理资源。

异常链示例：

try:
    int("abc")
except ValueError as exc:
    raise RuntimeError("parse config failed") from exc

这样外层看到 RuntimeError 的同时，也能看到原始 ValueError，排查时知道真正根因。

面试重点：不要裸 except: 吞掉所有异常；不要在 finally 里随意 return 覆盖异常；捕获异常要尽量具体，转换异常时保留上下文。

完整版教学

一、异常处理不是简单兜底

异常处理的目标不是把错误藏起来，而是让错误在合适的层级被理解、处理或转换。

错误示例：

try:
    do_work()
except Exception:
    pass

这会让真正的问题消失。程序看起来继续运行，但状态可能已经错了。

更好的做法是捕获具体异常：

try:
    value = int(text)
except ValueError:
    value = 0

这里你明确知道 int(text) 可能因为格式错误失败，也知道默认值策略是什么。

二、try/except/else/finally 的分工

完整结构：

try:
    ...
except SomeError:
    ...
else:
    ...
finally:
    ...

执行规则：

try 中发生匹配异常，进入对应 except；
try 中没有异常，执行 else；
finally 总会执行；
如果异常没有被处理，会在 finally 后继续向外传播。

else 的好处是让“可能抛异常的代码”和“成功后才做的事”分开：

try:
    user = load_user(user_id)
except UserNotFound:
    return None
else:
    return format_user(user)

三、finally 的常见坑

finally 适合清理资源：

lock.acquire()
try:
    update()
finally:
    lock.release()

但不要轻易在 finally 中 return：

def f():
    try:
        raise ValueError("bad")
    finally:
        return 1

这里异常会被 return 覆盖，调用方看不到 ValueError。这类代码很难排查。

资源管理更推荐上下文管理器：

with lock:
    update()

四、异常链是什么

当你捕获底层异常，并抛出更符合业务语义的新异常时，应该保留原始异常。

try:
    data = json.loads(text)
except json.JSONDecodeError as exc:
    raise ConfigError("invalid config json") from exc

这样 traceback 会显示：

外层是 ConfigError；
原因是 JSONDecodeError。

没有 from exc 时，Python 也可能显示上下文，但显式异常链更清晰，表达“这个新异常是由原异常导致的”。

五、什么时候自定义异常

自定义异常适合表达业务错误：

class InsufficientBalanceError(Exception):
    pass

使用：

if amount > balance:
    raise InsufficientBalanceError("balance is not enough")

好处是调用方可以捕获特定业务异常：

try:
    account.withdraw(100)
except InsufficientBalanceError:
    ...

不要所有错误都抛 Exception，否则调用方很难区分错误类型。

六、异常处理的工程建议

几个实用原则：

能捕获具体异常，就不要捕获大而泛的异常；
捕获后要么处理，要么记录并重新抛出；
异常转换时用 raise ... from ...；
不要用异常控制普通流程；
清理资源优先使用 with；
日志里保留 traceback。

异常处理写得好，系统失败时更容易定位问题。

七、常见误区与追问

心法：异常处理不是把错误藏起来，而是把错误转换成调用方能理解、能定位、能恢复的形式。该保留上下文时就用异常链。

误区：except Exception 是最稳的兜底方式。 它容易吞掉真实 bug，让调用方不知道失败原因；除非在边界层记录日志并重新抛出或转换异常，否则不应大范围裸捕获。
追问：else 子句有什么意义？ else 只在 try 块没有异常时执行，适合放依赖成功结果的逻辑，避免把不该捕获的代码也包进 try。
误区：finally 里 return 很方便。 finally 中的 return 会覆盖 try/except 中的返回值或异常，导致错误被静默吞掉，是面试和代码审查里的高危点。
追问：raise NewError from exc 和直接 raise NewError 有什么区别？ 前者显式保留原异常作为原因，traceback 会显示异常链；后者可能丢失因果关系，让排查更难。
误区：自定义异常越多越专业。 自定义异常应围绕业务边界和可恢复语义设计；如果只是换个名字包装所有错误，反而增加理解成本。
追问：什么时候用 raise 不带参数？ 在 except 块里想原样重新抛出当前异常时使用，它会保留原 traceback，比 raise exc 更适合保持现场。

八、加强记忆

异常处理要分清四块：try 放风险代码，except 处理具体错误，else 处理成功路径，finally 做清理。异常转换时用 raise ... from ... 保留根因。别裸捕获、别静默吞错、别在 finally 里乱 return。

简化版

详细版