作者腾讯蓝鲸智云·2022-08-12 16:44

系统运维工程师·腾讯科技（深圳）有限公司

Python 工匠：异常处理的三个好习惯

字数 5731阅读 551评论 0赞 0

# 前言

> 这是 “Python 工匠”系列的第 6 篇文章。（点击原文链接，可查看系列其他文章）

![](https://img-blog.csdnimg.cn/f90a067f88cd486ea4fd300ef6eb10b1.png)

如果你用 Python 编程，那么你就无法避开异常，因为异常在这门语言里无处不在。打个比方，当你在脚本执行时按 `ctrl+c` 退出，解释器就会产生一个 `KeyboardInterrupt` 异常。而 `KeyError`、 `ValueError`、 `TypeError` 等更是日常编程里随处可见的老朋友。

异常处理工作由“捕获”和“抛出”两部分组成。“捕获”指的是使用 `try...except` 包裹特定语句，妥当的完成错误流程处理。而恰当的使用 `raise` 主动“抛出”异常，更是优雅代码里必不可少的组成部分。

在这篇文章里，我会分享与异常处理相关的 3 个好习惯。继续阅读前，我希望你已经了解了下面这些知识点：

- 异常的基本语法与用法（建议阅读官方文档 “Errors and Exceptions”）

- 为什么要使用异常代替错误返回（建议阅读[《让函数返回结果的技巧》](http://mp.weixin.qq.com/s?__biz=Mzg2NjExNDI0MQ==&mid=2247483658&idx=1&sn=ac7222c597c2c063fab225af818a84af&chksm=ce4e8ea4f93907b2267ea873fd57b4a1c9cd640ee03d84f88672e0749472f91bbceb712083ce&scene=21#wechat_redirect)）

- 为什么在写 Python 时鼓励使用异常 （建议阅读 “Write Cleaner Python: Use Exceptions”）

---

# 三个好习惯

#### 1. 只做最精确的异常捕获

假如你不够了解异常机制，就难免会对它有一种天然恐惧感。你可能会觉得：异常是一种不好的东西，好的程序就应该捕获所有的异常，让一切都平平稳稳的运行。而抱着这种想法写出的代码，里面通常会出现大段含糊的异常捕获逻辑。

让我们用一段可执行脚本作为样例：

![](https://img-blog.csdnimg.cn/de24083a7ce34884b6c5255fa42c656a.png)

脚本里的 `save_website_title` 函数做了好几件事情。它首先通过网络获取网页内容，然后利用正则匹配出标题，最后将标题写在本地文件里。而这里有两个步骤很容易出错：网络请求 与 本地文件操作。所以在代码里，我们用一个大大的 `try...except` 语句块，将这几个步骤都包裹了起来。安全第一。

那么，这段看上去简洁易懂的代码，里面藏着什么问题呢？

如果你旁边刚好有一台安装了 Python 的电脑，那么你可以试着跑一遍上面的脚本。你会发现，上面的代码是不能成功执行的。而且你还会发现，无论你如何修改网址和目标文件的值，程序仍然会报错 `“save failed: unable to...”`。为什么呢？

问题就藏在这个硕大无比的 `try...except` 语句块里。假如你把眼睛贴近屏幕，非常仔细的检查这段代码。你会发现在编写函数时，我犯了一个小错误，我把获取正则匹配串的方法错打成了 `obj.grop(1)`，少了一个 `'u'（ obj.group(1)）`。

但正是因为那个过于庞大、含糊的异常捕获，这个由打错方法名导致的原本该被抛出的 `AttibuteError` 却被吞噬了。从而给我们的 `debug` 过程增加了不必要的麻烦。

异常捕获的目的，不是去捕获尽可能多的异常。假如我们从一开始就坚持：只做最精准的异常捕获。那么这样的问题就根本不会发生，精准捕获包括：

- 永远只捕获那些可能会抛出异常的语句块

- 尽量只捕获精确的异常类型，而不是模糊的 `Exception`

依照这个原则，我们的样例应该被改成这样：

![](https://img-blog.csdnimg.cn/c839ed9cfcd24fb390fd644185587ab7.png)

#### 2. 别让异常破坏抽象一致性

大约四五年前，当时的我正在开发某移动应用的后端 API 项目。如果你也有过开发后端 API 的经验，那么你一定知道，这样的系统都需要制定一套“API 错误码规范”，来为客户端处理调用错误时提供方便。

一个错误码返回大概长这个样子：

![](https://img-blog.csdnimg.cn/fecc8fe389804fa4953d03d65c905609.png)

在制定好错误码规范后，接下来的任务就是如何实现它。当时的项目使用了 Django 框架，而 Django 的错误页面正是使用了异常机制实现的。打个比方，如果你想让一个请求返回 404 状态码，那么只要在该请求处理过程中执行 `raiseHttp404` 即可。

所以，我们很自然的从 Django 获得了灵感。首先，我们在项目内定义了错误码异常类：`APIErrorCode`。然后依据“错误码规范”，写了很多继承该类的错误码。当需要返回错误信息给用户时，只需要做一次 `raise` 就能搞定。

![](https://img-blog.csdnimg.cn/3f1e49f5fc464a0f8d47ed048bf57713.png)

毫无意外，所有人都很喜欢用这种方式来返回错误码。因为它用起来非常方便，无论调用栈多深，只要你想给用户返回错误码，调用 `raiseerror_codes.ANY_THING` 就好。

随着时间推移，项目也变得越来越庞大，抛出 `APIErrorCode` 的地方也越来越多。有一天，我正准备复用一个底层图片处理函数时，突然碰到了一个问题。

我看到了一段让我非常纠结的代码：

![](https://img-blog.csdnimg.cn/a05676c7f3e64c0d9c10bb99f29d69ed.png)

`process_image` 函数会尝试解析一个文件对象，如果该对象不能被作为图片正常打开，就抛出 `error_codes.INVALID_IMAGE_UPLOADED`（APIErrorCode子类） 异常，从而给调用方返回错误代码 JSON。

让我给你从头理理这段代码。最初编写 `process_image` 时，我虽然把它放在了 `util.image` 模块里，但当时调这个函数的地方就只有 “处理用户上传图片的 POST 请求” 而已。为了偷懒，我让函数直接抛出 `APIErrorCode` 异常来完成了错误处理工作。

再来说当时的问题。那时我需要写一个在后台运行的批处理图片脚本，而它刚好可以复用 `process_image` 函数所实现的功能。但这时不对劲的事情出现了，如果我想复用该函数，那么：

- 我必须去捕获一个名为 `INVALID_IMAGE_UPLOADED` 的异常

- 哪怕我的图片根本就不是来自于用户上传

- 我必须引入 `APIErrorCode` 异常类作为依赖来捕获异常

- 哪怕我的脚本和 `Django API` 根本没有任何关系

这就是异常类抽象层级不一致导致的结果。`APIErrorCode` 异常类的意义，在于表达一种能够直接被终端用户（人）识别并消费的“错误代码”。它在整个项目里，属于最高层的抽象之一。但是出于方便，我们却在底层模块里引入并抛出了它。这打破了 `image.processor` 模块的抽象一致性，影响了它的可复用性和可维护性。

这类情况属于“模块抛出了高于所属抽象层级的异常”。避免这类错误需要注意以下几点：

- 让模块只抛出与当前抽象层级一致的异常

- 比如 `image.processer` 模块应该抛出自己封装的 `ImageOpenError` 异常

- 在必要的地方进行异常包装与转换

- 比如，应该在贴近高层抽象（视图 View 函数）的地方，将图像处理模块的 `ImageOpenError` 低级异常包装转换为 `APIErrorCode` 高级异常

修改后的代码：

![](https://img-blog.csdnimg.cn/1501a3faa918482e87a6591f1bdafabf.png)

除了应该避免抛出高于当前抽象级别的异常外，我们同样应该避免泄露低于当前抽象级别的异常。

如果你用过 `requests` 模块，你可能已经发现它请求页面出错时所抛出的异常，并不是它在底层所使用的 `urllib3` 模块的原始异常，而是通过 `requests.exceptions` 包装过一次的异常。

![](https://img-blog.csdnimg.cn/34e7f9005d6740689822401aab9d6f83.png)

这样做同样是为了保证异常类的抽象一致性。因为 `urllib3` 模块是 `requests` 模块依赖的底层实现细节，而这个细节有可能在未来版本发生变动。所以必须对它抛出的异常进行恰当的包装，避免未来的底层变更对 `requests` 用户端错误处理逻辑产生影响。

#### 3. 异常处理不应该喧宾夺主

在前面我们提到异常捕获要精准、抽象级别要一致。但在现实世界中，如果你严格遵循这些流程，那么很有可能会碰上另外一个问题：异常处理逻辑太多，以至于扰乱了代码核心逻辑。具体表现就是，代码里充斥着大量的 `try、 except、 raise` 语句，让核心逻辑变得难以辨识。

让我们看一段例子：

![](https://img-blog.csdnimg.cn/2853add9c85d43dc86404290cfb29fd2.png)

这是一个处理用户上传头像的视图函数。这个函数内做了三件事情，并且针对每件事都做了异常捕获。如果做某件事时发生了异常，就返回对用户友好的错误到前端。

这样的处理流程纵然合理，但是显然代码里的异常处理逻辑有点“喧宾夺主”了。一眼看过去全是代码缩进，很难提炼出代码的核心逻辑。

早在 2.5 版本时，Python 语言就已经提供了对付这类场景的工具：“上下文管理器（context manager）”。上下文管理器是一种配合 with 语句使用的特殊 Python 对象，通过它，可以让异常处理工作变得更方便。

那么，如何利用上下文管理器来改善我们的异常处理流程呢？让我们直接看代码吧。

![](https://img-blog.csdnimg.cn/da81e654859c4bfabeaa7984ec41e70f.png)

在上面的代码里，我们定义了一个名为 `raise_api_error` 的上下文管理器，它在进入上下文时什么也不做。但是在退出上下文时，会判断当前上下文中是否抛出了类型为 `self.captures` 的异常，如果有，就用 `APIErrorCode` 异常类替代它。

使用该上下文管理器后，整个函数可以变得更清晰简洁：

![](https://img-blog.csdnimg.cn/2b07b12f8d2a481fa5787424598900fa.png)

> Hint：建议阅读 PEP 343 -- The "with" Statement | Python.org，了解与上下文管理器有关的更多知识。

> 模块 contextlib 也提供了非常多与编写上下文管理器相关的工具函数与样例。

---

# 总结

在这篇文章中，我分享了与异常处理相关的三个建议。最后再总结一下要点：

- 只捕获可能会抛出异常的语句，避免含糊的捕获逻辑

- 保持模块异常类的抽象一致性，必要时对底层异常类进行包装

- 使用“上下文管理器”可以简化重复的异常处理逻辑

看完文章的你，有没有什么想吐槽的？请留言或者在 项目 Github Issues 告诉我吧。

---

# 附录

- 题图来源: Photo by Bernard Hermant on Unsplash

- 更多系列文章地址：https://github.com/piglei/one-python-craftsman

系列其他文章：

- [Python 工匠：让函数返回结果的技巧](http://mp.weixin.qq.com/s?__biz=Mzg2NjExNDI0MQ==&mid=2247483658&idx=1&sn=ac7222c597c2c063fab225af818a84af&chksm=ce4e8ea4f93907b2267ea873fd57b4a1c9cd640ee03d84f88672e0749472f91bbceb712083ce&scene=21#wechat_redirect)

---

# 蓝鲸智云

本文由腾讯蓝鲸智云编辑发布，腾讯蓝鲸智云（简称蓝鲸）软件体系是一套基于PaaS的技术解决方案，致力于打造行业领先的一站式自动化运维平台。目前已经推出社区版、企业版，欢迎体验。

- 官网：https://bk.tencent.com/

- 下载链接：https://bk.tencent.com/download/

- 社区：https://bk.tencent.com/s-mart/community/question

Python 工匠

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

Python 工匠：异常处理的三个好习惯

添加新评论0 条评论

作者其他文章

相关文章

Python 工匠： 异常处理的三个好习惯

添加新评论0 条评论

作者其他文章

相关文章

Python 工匠：异常处理的三个好习惯