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

论坛 › 期权论坛 › 期权     
进击的Coder   2019-7-14 05:27   2729   0
今天依然推荐 Python 工匠系列文章，给大家介绍异常处理值得注意的地方。[h1]今天依然推荐 Python 工匠系列文章，给大家介绍异常处理值得注意的地方。[/h1]转载来源
公众号：piglei
“ 阅读本文大概需要 9 分钟。


”[h1]前言[/h1]如果你用 Python 编程，那么你就无法避开异常，因为异常在这门语言里无处不在。打个比方，当你在脚本执行时按
  1. ctrl+c
复制代码
退出，解释器就会产生一个
  1. KeyboardInterrupt
复制代码
异常。而
  1. KeyError
复制代码
、
  1. ValueError
复制代码
、
  1. TypeError
复制代码
等更是日常编程里随处可见的老朋友。
异常处理工作由“捕获”和“抛出”两部分组成。“捕获”指的是使用
  1. try...except
复制代码
包裹特定语句，妥当的完成错误流程处理。而恰当的使用
  1. raise
复制代码
主动“抛出”异常，更是优雅代码里必不可少的组成部分。
在这篇文章里，我会分享与异常处理相关的 3 个好习惯。继续阅读前，我希望你已经了解了下面这些知识点：
  • 异常的基本语法与用法（建议阅读官方文档 “Errors and Exceptions”）
  • 为什么要使用异常代替错误返回（建议阅读《让函数返回结果的技巧》）
  • 为什么在写 Python 时鼓励使用异常 （建议阅读 “Write Cleaner Python: Use Exceptions”）
[h1]三个好习惯[/h1][h2]1. 只做最精确的异常捕获[/h2]假如你不够了解异常机制，就难免会对它有一种天然恐惧感。你可能会觉得：异常是一种不好的东西，好的程序就应该捕获所有的异常，让一切都平平稳稳的运行。而抱着这种想法写出的代码，里面通常会出现大段含糊的异常捕获逻辑。
让我们用一段可执行脚本作为样例：
    1. # -*- coding: utf-8 -*-
    复制代码
    1. import requests
    复制代码
    1. import re
    复制代码


    1. def save_website_title(url, filename):
    复制代码
    1.     """获取某个地址的网页标题，然后将其写入到文件中
    复制代码

    1.     :returns: 如果成功保存，返回 True，否则打印错误，返回 False
    复制代码
    1.     """
    复制代码
    1.     try:
    复制代码
    1.         resp = requests.get(url)
    复制代码
    1.         obj = re.search(r'(.*)', resp.text)
    复制代码
    1.         if not obj:
    复制代码
    1.             print('save failed: title tag not found in page content')
    复制代码
    1.             return False
    复制代码

    1.         title = obj.grop(1)
    复制代码
    1.         with open(filename, 'w') as fp:
    复制代码
    1.             fp.write(title)
    复制代码
    1.             return True
    复制代码
    1.     except Exception:
    复制代码
    1.         print(f'save failed: unable to save title of {url} to {filename}')
    复制代码
    1.         return False
    复制代码


    1. def main():
    复制代码
    1.     save_website_title('https://www.qq.com', 'qq_title.txt')
    复制代码


    1. if __name__ == '__main__':
    复制代码
    1.     main()
    复制代码
脚本里的
  1. save_website_title
复制代码
函数做了好几件事情。它首先通过网络获取网页内容，然后利用正则匹配出标题，最后将标题写在本地文件里。而这里有两个步骤很容易出错：网络请求 与 本地文件操作。所以在代码里，我们用一个大大的
  1. try...except
复制代码
语句块，将这几个步骤都包裹了起来。安全第一 。
那么，这段看上去简洁易懂的代码，里面藏着什么问题呢？
如果你旁边刚好有一台安装了 Python 的电脑，那么你可以试着跑一遍上面的脚本。你会发现，上面的代码是不能成功执行的。而且你还会发现，无论你如何修改网址和目标文件的值，程序仍然会报错 “save failed: unable to...”。为什么呢？
问题就藏在这个硕大无比的
  1. try...except
复制代码
语句块里。假如你把眼睛贴近屏幕，非常仔细的检查这段代码。你会发现在编写函数时，我犯了一个小错误，我把获取正则匹配串的方法错打成了
  1. obj.grop(1)
复制代码
，少了一个 'u'（
  1. obj.group(1)
复制代码
）。
但正是因为那个过于庞大、含糊的异常捕获，这个由打错方法名导致的原本该被抛出的
  1. AttibuteError
复制代码
却被吞噬了。从而给我们的 debug 过程增加了不必要的麻烦。
异常捕获的目的，不是去捕获尽可能多的异常。假如我们从一开始就坚持：只做最精准的异常捕获。那么这样的问题就根本不会发生，精准捕获包括：
  • 永远只捕获那些可能会抛出异常的语句块
  • 尽量只捕获精确的异常类型，而不是模糊的
    1. Exception
    复制代码
依照这个原则，我们的样例应该被改成这样：
    1. from requests.exceptions import RequestException
    复制代码


    1. def save_website_title(url, filename):
    复制代码
    1.     try:
    复制代码
    1.         resp = requests.get(url)
    复制代码
    1.     except RequestException as e:
    复制代码
    1.         print(f'save failed: unable to get page content: {e}')
    复制代码
    1.         return False
    复制代码

    1.     # 这段正则操作本身就是不应该抛出异常的，所以我们没必要使用 try 语句块
    复制代码
    1.     # 假如 group 被误打成了 grop 也没关系，程序马上就会通过 AttributeError 来
    复制代码
    1.     # 告诉我们。
    复制代码
    1.     obj = re.search(r'(.*)', resp.text)
    复制代码
    1.     if not obj:
    复制代码
    1.         print('save failed: title tag not found in page content')
    复制代码
    1.         return False
    复制代码
    1.     title = obj.group(1)
    复制代码

    1.     try:
    复制代码
    1.         with open(filename, 'w') as fp:
    复制代码
    1.             fp.write(title)
    复制代码
    1.     except IOError as e:
    复制代码
    1.         print(f'save failed: unable to write to file {filename}: {e}')
    复制代码
    1.         return False
    复制代码
    1.     else:
    复制代码
    1.         return True
    复制代码
[h2]2. 别让异常破坏抽象一致性[/h2]大约四五年前，当时的我正在开发某移动应用的后端 API 项目。如果你也有过开发后端 API 的经验，那么你一定知道，这样的系统都需要制定一套“API 错误码规范”，来为客户端处理调用错误时提供方便。
一个错误码返回大概长这个样子：
    1. // HTTP Status Code: 400
    复制代码
    1. // Content-Type: application/json
    复制代码
    1. {
    复制代码
    1.     "code": "UNABLE_TO_UPVOTE_YOUR_OWN_REPLY",
    复制代码
    1.     "detail": "你不能推荐自己的回复"
    复制代码
    1. }
    复制代码
在制定好错误码规范后，接下来的任务就是如何实现它。当时的项目使用了 Django 框架，而 Django 的错误页面正是使用了异常机制实现的。打个比方，如果你想让一个请求返回 404 状态码，那么只要在该请求处理过程中执行
  1. raiseHttp404
复制代码
即可。
所以，我们很自然的从 Django 获得了灵感。首先，我们在项目内定义了错误码异常类：
  1. APIErrorCode
复制代码
。然后依据“错误码规范”，写了很多继承该类的错误码。当需要返回错误信息给用户时，只需要做一次
  1. raise
复制代码
就能搞定。
    1. raise error_codes.UNABLE_TO_UPVOTE
    复制代码
    1. raise error_codes.USER_HAS_BEEN_BANNED
    复制代码
    1. ... ...
    复制代码
毫无意外，所有人都很喜欢用这种方式来返回错误码。因为它用起来非常方便，无论调用栈多深，只要你想给用户返回错误码，调用
  1. raiseerror_codes.ANY_THING
复制代码
就好。
随着时间推移，项目也变得越来越庞大，抛出
  1. APIErrorCode
复制代码
的地方也越来越多。有一天，我正准备复用一个底层图片处理函数时，突然碰到了一个问题。
我看到了一段让我非常纠结的代码：
    1. # 在某个处理图像的模块内部
    复制代码
    1. # /util/image/processor.py
    复制代码
    1. def process_image(...):
    复制代码
    1.     try:
    复制代码
    1.         image = Image.open(fp)
    复制代码
    1.     except Exception:
    复制代码
    1.         # 说明（非项目原注释）：该异常将会被 Django 的中间件捕获，往前端返回
    复制代码
    1.         # "上传的图片格式有误" 信息
    复制代码
    1.         raise error_codes.INVALID_IMAGE_UPLOADED
    复制代码
    1.     ... ...
    复制代码
  1. process_image
复制代码
函数会尝试解析一个文件对象，如果该对象不能被作为图片正常打开，就抛出
  1. error_codes.INVALID_IMAGE_UPLOADED（APIErrorCode子类）
复制代码
异常，从而给调用方返回错误代码 JSON。
让我给你从头理理这段代码。最初编写
  1. process_image
复制代码
时，我虽然把它放在了
  1. util.image
复制代码
模块里，但当时调这个函数的地方就只有 “处理用户上传图片的 POST 请求” 而已。为了偷懒，我让函数直接抛出
  1. APIErrorCode
复制代码
异常来完成了错误处理工作。
再来说当时的问题。那时我需要写一个在后台运行的批处理图片脚本，而它刚好可以复用
  1. process_image
复制代码
函数所实现的功能。但这时不对劲的事情出现了，如果我想复用该函数，那么：
  • 我必须去捕获一个名为
    1. INVALID_IMAGE_UPLOADED
    复制代码
    的异常
    • 哪怕我的图片根本就不是来自于用户上传
  • 我必须引入
    1. APIErrorCode
    复制代码
    异常类作为依赖来捕获异常
    • 哪怕我的脚本和 Django API 根本没有任何关系
这就是异常类抽象层级不一致导致的结果。APIErrorCode 异常类的意义，在于表达一种能够直接被终端用户（人）识别并消费的“错误代码”。它在整个项目里，属于最高层的抽象之一。但是出于方便，我们却在底层模块里引入并抛出了它。这打破了
  1. image.processor
复制代码
模块的抽象一致性，影响了它的可复用性和可维护性。
这类情况属于“模块抛出了高于所属抽象层级的异常”。避免这类错误需要注意以下几点：
  • 让模块只抛出与当前抽象层级一致的异常
    • 比如
      1. image.processer
      复制代码
      模块应该抛出自己封装的
      1. ImageOpenError
      复制代码
      异常
  • 在必要的地方进行异常包装与转换
    • 比如，应该在贴近高层抽象（视图 View 函数）的地方，将图像处理模块的
      1. ImageOpenError
      复制代码
      低级异常包装转换为
      1. APIErrorCode
      复制代码
      高级异常
修改后的代码：
    1. # /util/image/processor.py
    复制代码
    1. class ImageOpenError(Exception):
    复制代码
    1.     pass
    复制代码


    1. def process_image(...):
    复制代码
    1.     try:
    复制代码
    1.         image = Image.open(fp)
    复制代码
    1.     except Exception as e:
    复制代码
    1.         raise ImageOpenError(exc=e)
    复制代码
    1.     ... ...
    复制代码

    1. # /app/views.py
    复制代码
    1. def foo_view_function(request):
    复制代码
    1.     try:
    复制代码
    1.         process_image(fp)
    复制代码
    1.     except ImageOpenError:
    复制代码
    1.         raise error_codes.INVALID_IMAGE_UPLOADED
    复制代码
除了应该避免抛出高于当前抽象级别的异常外，我们同样应该避免泄露低于当前抽象级别的异常。
如果你用过
  1. requests
复制代码
模块，你可能已经发现它请求页面出错时所抛出的异常，并不是它在底层所使用的
  1. urllib3
复制代码
模块的原始异常，而是通过
  1. requests.exceptions
复制代码
包装过一次的异常。
    1. >>> try:
    复制代码
    1. ...     requests.get('https://www.invalid-host-foo.com')
    复制代码
    1. ... except Exception as e:
    复制代码
    1. ...     print(type(e))
    复制代码
    1. ...
    复制代码
    1. [/code]
    2. [/list]这样做同样是为了保证异常类的抽象一致性。因为 urllib3 模块是 requests 模块依赖的底层实现细节，而这个细节有可能在未来版本发生变动。所以必须对它抛出的异常进行恰当的包装，避免未来的底层变更对 [code]requests
    复制代码
    用户端错误处理逻辑产生影响。
    [h2]3. 异常处理不应该喧宾夺主[/h2]在前面我们提到异常捕获要精准、抽象级别要一致。但在现实世界中，如果你严格遵循这些流程，那么很有可能会碰上另外一个问题：异常处理逻辑太多，以至于扰乱了代码核心逻辑。具体表现就是，代码里充斥着大量的
    1. try
    复制代码
    、
    1. except
    复制代码
    、
    1. raise
    复制代码
    语句，让核心逻辑变得难以辨识。
    让我们看一段例子：
      1. def upload_avatar(request):
      复制代码
      1.     """用户上传新头像"""
      复制代码
      1.     try:
      复制代码
      1.         avatar_file = request.FILES['avatar']
      复制代码
      1.     except KeyError:
      复制代码
      1.         raise error_codes.AVATAR_FILE_NOT_PROVIDED
      复制代码

      1.     try:
      复制代码
      1.        resized_avatar_file = resize_avatar(avatar_file)
      复制代码
      1.     except FileTooLargeError as e:
      复制代码
      1.         raise error_codes.AVATAR_FILE_TOO_LARGE
      复制代码
      1.     except ResizeAvatarError as e:
      复制代码
      1.         raise error_codes.AVATAR_FILE_INVALID
      复制代码

      1.     try:
      复制代码
      1.         request.user.avatar = resized_avatar_file
      复制代码
      1.         request.user.save()
      复制代码
      1.     except Exception:
      复制代码
      1.         raise error_codes.INTERNAL_SERVER_ERROR
      复制代码
      1.     return HttpResponse({})
      复制代码
    这是一个处理用户上传头像的视图函数。这个函数内做了三件事情，并且针对每件事都做了异常捕获。如果做某件事时发生了异常，就返回对用户友好的错误到前端。
    这样的处理流程纵然合理，但是显然代码里的异常处理逻辑有点“喧宾夺主”了。一眼看过去全是代码缩进，很难提炼出代码的核心逻辑。
    早在 2.5 版本时，Python 语言就已经提供了对付这类场景的工具：“上下文管理器（context manager）”。上下文管理器是一种配合
    1. with
    复制代码
    语句使用的特殊 Python 对象，通过它，可以让异常处理工作变得更方便。
    那么，如何利用上下文管理器来改善我们的异常处理流程呢？让我们直接看代码吧。
      1. class raise_api_error:
      复制代码
      1.     """captures specified exception and raise ApiErrorCode instead
      复制代码

      1.     :raises: AttributeError if code_name is not valid
      复制代码
      1.     """
      复制代码
      1.     def __init__(self, captures, code_name):
      复制代码
      1.         self.captures = captures
      复制代码
      1.         self.code = getattr(error_codes, code_name)
      复制代码

      1.     def __enter__(self):
      复制代码
      1.         # 刚方法将在进入上下文时调用
      复制代码
      1.         return self
      复制代码

      1.     def __exit__(self, exc_type, exc_val, exc_tb):
      复制代码
      1.         # 该方法将在退出上下文时调用
      复制代码
      1.         # exc_type, exc_val, exc_tb 分别表示该上下文内抛出的
      复制代码
      1.         # 异常类型、异常值、错误栈
      复制代码
      1.         if exc_type is None:
      复制代码
      1.             return False
      复制代码

      1.         if exc_type == self.captures:
      复制代码
      1.             raise self.code from exc_val
      复制代码
      1.         return False
      复制代码
    在上面的代码里，我们定义了一个名为
    1. raise_api_error
    复制代码
    的上下文管理器，它在进入上下文时什么也不做。但是在退出上下文时，会判断当前上下文中是否抛出了类型为
    1. self.captures
    复制代码
    的异常，如果有，就用
    1. APIErrorCode
    复制代码
    异常类替代它。
    使用该上下文管理器后，整个函数可以变得更清晰简洁：
      1. def upload_avatar(request):
      复制代码
      1.     """用户上传新头像"""
      复制代码
      1.     with raise_api_error(KeyError, 'AVATAR_FILE_NOT_PROVIDED'):
      复制代码
      1.         avatar_file = request.FILES['avatar']
      复制代码

      1.     with raise_api_error(ResizeAvatarError, 'AVATAR_FILE_INVALID'),
      复制代码
      1.             raise_api_error(FileTooLargeError, 'AVATAR_FILE_TOO_LARGE'):
      复制代码
      1.         resized_avatar_file = resize_avatar(avatar_file)
      复制代码

      1.     with raise_api_error(Exception, 'INTERNAL_SERVER_ERROR'):
      复制代码
      1.         request.user.avatar = resized_avatar_file
      复制代码
      1.         request.user.save()
      复制代码
      1.     return HttpResponse({})
      复制代码
    Hint：建议阅读 PEP 343 -- The "with" Statement | Python.org，了解与上下文管理器有关的更多知识。
    模块 contextlib 也提供了非常多与编写上下文管理器相关的工具函数与样例。
    [h1]总结[/h1]在这篇文章中，我分享了与异常处理相关的三个建议。最后再总结一下要点：
    • 只捕获可能会抛出异常的语句，避免含糊的捕获逻辑
    • 保持模块异常类的抽象一致性，必要时对底层异常类进行包装
    • 使用“上下文管理器”可以简化重复的异常处理逻辑
    看完文章的你，有没有什么想吐槽的？请留言或者在 项目 Github Issues 告诉我吧。
    [h1]附录[/h1]
    • 题图来源: Photo by Bernard Hermant on Unsplash
    • 更多系列文章地址：https://github.com/piglei/one-python-craftsman
    推荐阅读

    1
    跟繁琐的命令行说拜拜！Gerapy分布式爬虫管理框架来袭！
    2
    跟繁琐的模型说拜拜！深度学习脚手架 ModelZoo 来袭！

    3
    只会用Selenium爬网页？Appium爬App了解一下
    4

    妈妈再也不用担心爬虫被封号了！手把手教你搭建Cookies池
    崔庆才
    静觅博客博主，《Python3网络爬虫开发实战》作者
    隐形字
    个人公众号：进击的Coder


    长按识别二维码关注

    好文和朋友一起看~
回复
分享到 :
0 人收藏
返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

2级吧友
进击的Coder

积分:15
帖子:3
精华:0
+ 关注 私信
期权论坛 期权论坛
期权网络科技版权所有
关于我们
联系我们
加入我们
反馈问题
免责声明
积分充值
统一社会信用代码
积分规则
网站地图
爱文库
下属网站
官方
新浪微博
微信公众号
◆
下载
表情包
App下载
期权论坛 期权论坛

QQ咨询|关于我们|Archiver|手机版|小黑屋|( 辽ICP备15012455号-4 ) Powered by 期权论坛 X3.2 © 2001-2016 期权工具网&期权论坛 Inc.

发布
内容

下载期权论坛手机APP