那天凌晨三点。我盯着显示器，脸色惨白。生产环境刚刚因为一个未捕获的异常整个崩溃了。客户数据丢了一部分，老板电话已经打来三个。就因为我天真地以为那个API永远不会返回空值…这事发生在我Python生涯的第二年。痛定思痛，我决定彻底研究异常处理。

Python的异常机制其实挺有趣的。Guido最初设计它时受到了ABC语言的启发，希望避免C语言里那种容易被忽略的错误码检查。他想让错误处理变得明确、优雅。

可现实是什么样？

1# 大多数人的异常处理长这样

2try：

3    do_something()

4except Exception as e：  # 偷懒大法！

5    print(f"出错了： {e}")

6    # 然后呢？然后就没有然后了...

我管这叫"鸵鸟式异常处理"——把头埋进沙子里，假装问题解决了。事实上，这种代码在生产环境简直就是定时炸弹！

异常处理应该怎么做？我从血泪教训中总结出几条黄金法则：

1. 只捕获预期的异常

1try：

2    config = json.loads(config_str)

3except json.JSONDecodeError：  # 具体异常类型！

4    logger.error("配置文件格式错误")

5    config = default_config

6except UnicodeDecodeError：

7    # 另一种可能的错误

8    logger.error("配置文件编码错误")

9    config = default_config

这比捕获所有异常好太多了！它让你的代码表明了意图。

知道吗？任何时候当你写下except Exception，Python社区里就会有一个资深开发者感到一阵心痛…

2. 设计层次化的自定义异常

那年项目重构，我设计了一套异常体系。小伙伴们起初不理解，后来却欲罢不能。

 1class ServiceError(Exception)：

 2    """服务基础异常"""

 3    pass

 4

 5class DatabaseError(ServiceError)：

 6    """数据库相关异常"""

 7    pass

 8

 9class QueryError(DatabaseError)：

10    """查询错误"""

11    def __init__(self， query， message="查询执行失败")：

12        self.query = query

13        self.message = message

14        super().__init__(self.message)

15

层次化设计让调用方可以根据需要选择精确度不同的异常捕获。PEP 3151就是这样的思想。

这样写日志时还能附带更多上下文！调试效率直接翻倍。

3. 异常粒度要适中

太粗太细都不行。

太粗的例子——只有一个AppError类。啥错误都用它。区分不了根本原因！

太细呢？为每个函数单独设计异常类。代码库里塞满了几百个异常类，没人记得清用哪个。

理想状态是按照功能模块设计10-20个异常类。我们公司API服务大概有15个异常类，覆盖了99%的错误场景。

4. 异常要包含足够上下文

看看这两个区别：

1# 糟糕示例

2raise ValueError("Invalid value")

3

4# 优秀示例

5raise ValueError(

6    f"User ID must be positive integer， got {user_id} ({type(user_id)})"

7)

前者让人一头雾水。后者直接告诉你：参数值是什么，类型是什么，预期是什么。

现在我每次看到没有上下文的异常信息就肝疼…

5. 知道何时处理、何时传播

最近Code Review时，看到实习生写了这样的代码：

1def process_data(data)：

2    try：

3        process_item(data)

4    except Exception as e：

5        # 问题来了：这里应该处理异常吗？

6        pass  # 不！这是罪恶的静默失败！

7

我问他："这个函数是否了解如何修复这个错误？"

他摇头。

"那就让异常继续传播，由知道如何处理的调用方来解决。"这是我给他的建议。

Python 3.11新增了异常组（Exception Groups）和except*语法，让异常处理更强大。当然，高级特性适度使用就好。

一些务实建议

上周帮朋友的创业公司重构代码，发现他们滥用异常处理影响了性能。用Python的profiler测试后发现，异常处理耗费了近8%的CPU时间！

原来他们把异常当控制流用了：

1# 反面教材

2def get_config_value(key)：

3    try：

4        return configs[key]

5    except KeyError：

6        return default_config[key]

7

这在Python里效率极低！异常处理的开销远大于简单的条件判断。改成这样性能提升了40倍(在我的M1 MacBook上测试)：

1# 优化版本

2def get_config_value(key)：

3    if key in configs：

4        return configs[key]

5    return default_config[key]

6

最后一条忠告：别怕写try-except。没有异常处理的代码根本不算完整。那些看似"正常"的API也会在深夜给你惊喜…我已经吃过太多亏了。

我现在的原则是——宁可捕获十次不会发生的异常，也不要放过一个可能的错误。

毕竟，谁想在凌晨三点被老板电话叫醒呢？