关于前端:Python-工匠-异常处理的三个好习惯

28次阅读

共计 3932 个字符,预计需要花费 10 分钟才能阅读完成。

前言

这是“Python 工匠”系列的第 6 篇文章。(点击原文链接,可查看系列其余文章)

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

异样解决工作由“捕捉”和“抛出”两局部组成。“捕捉”指的是应用 try...except 包裹特定语句,得当的实现谬误流程解决。而失当的应用 raise 被动“抛出”异样,更是优雅代码里必不可少的组成部分。

在这篇文章里,我会分享与异样解决相干的 3 个好习惯。持续浏览前,我心愿你曾经理解了上面这些知识点:

  • 异样的根本语法与用法(倡议浏览官网文档“Errors and Exceptions”)
  • 为什么要应用异样代替谬误返回(倡议浏览《让函数返回后果的技巧》)
  • 为什么在写 Python 时激励应用异样(倡议浏览“Write Cleaner Python: Use Exceptions”)

三个好习惯

1. 只做最准确的异样捕捉

如果你不够理解异样机制,就难免会对它有一种人造恐惧感。你可能会感觉:异样是一种不好的货色,好的程序就应该捕捉所有的异样,让所有都平平稳稳的运行。而抱着这种想法写出的代码,外面通常会呈现大段含混的异样捕捉逻辑。

让咱们用一段可执行脚本作为样例:

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

那么,这段看上去简洁易懂的代码,外面藏着什么问题呢?

如果你旁边刚好有一台装置了 Python 的电脑,那么你能够试着跑一遍下面的脚本。你会发现,下面的代码是不能胜利执行的。而且你还会发现,无论你如何批改网址和指标文件的值,程序依然会报错 “save failed: unable to...”。为什么呢?

问题就藏在这个硕大无比的 try...except 语句块里。如果你把眼睛贴近屏幕,十分认真的查看这段代码。你会发现在编写函数时,我犯了一个小谬误,我把获取正则匹配串的办法错打成了 obj.grop(1),少了一个 'u'(obj.group(1))

但正是因为那个过于宏大、含混的异样捕捉,这个由打错办法名导致的本来该被抛出的 AttibuteError 却被吞噬了。从而给咱们的 debug 过程减少了不必要的麻烦。

异样捕捉的目标,不是去捕捉尽可能多的异样。如果咱们从一开始就保持:只做最精准的异样捕捉。那么这样的问题就基本不会产生,精准捕捉包含:

  • 永远只捕捉那些可能会抛出异样的语句块
  • 尽量只捕捉准确的异样类型,而不是含糊的 Exception

按照这个准则,咱们的样例应该被改成这样:

2. 别让异样毁坏形象一致性

大概四五年前,过后的我正在开发某挪动利用的后端 API 我的项目。如果你也有过开发后端 API 的教训,那么你肯定晓得,这样的零碎都须要制订一套“API 错误码标准”,来为客户端解决调用谬误时提供方便。

一个错误码返回大略长这个样子:

在制订好错误码标准后,接下来的工作就是如何实现它。过后的我的项目应用了 Django 框架,而 Django 的谬误页面正是应用了异样机制实现的。打个比方,如果你想让一个申请返回 404 状态码,那么只有在该申请处理过程中执行 raiseHttp404 即可。

所以,咱们很天然的从 Django 取得了灵感。首先,咱们在我的项目内定义了错误码异样类:APIErrorCode。而后根据“错误码标准”,写了很多继承该类的错误码。当须要返回错误信息给用户时,只须要做一次 raise 就能搞定。

毫无意外,所有人都很喜爱用这种形式来返回错误码。因为它用起来十分不便,无论调用栈多深,只有你想给用户返回错误码,调用 raiseerror_codes.ANY_THING 就好。

随着时间推移,我的项目也变得越来越宏大,抛出 APIErrorCode 的中央也越来越多。有一天,我正筹备复用一个底层图片处理函数时,忽然碰到了一个问题。

我看到了一段让我十分纠结的代码:

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 高级异样

批改后的代码:

除了应该防止抛出高于以后形象级别的异样外,咱们同样应该防止泄露低于以后形象级别的异样。

如果你用过 requests 模块,你可能曾经发现它申请页面出错时所抛出的异样,并不是它在底层所应用的 urllib3 模块的原始异样,而是通过 requests.exceptions 包装过一次的异样。

这样做同样是为了保障异样类的形象一致性。因为 urllib3 模块是 requests 模块依赖的底层实现细节,而这个细节有可能在将来版本产生变动。所以必须对它抛出的异样进行失当的包装,防止将来的底层变更对 requests 用户端错误处理逻辑产生影响。

3. 异样解决不应该喧宾夺主

在后面咱们提到异样捕捉要精准、形象级别要统一。但在事实世界中,如果你严格遵循这些流程,那么很有可能会碰上另外一个问题:异样解决逻辑太多,以至于扰乱了代码外围逻辑。具体表现就是,代码里充斥着大量的 try、except、raise 语句,让外围逻辑变得难以辨识。

让咱们看一段例子:

这是一个解决用户上传头像的视图函数。这个函数内做了三件事件,并且针对每件事都做了异样捕捉。如果做某件事时产生了异样,就返回对用户敌对的谬误到前端。

这样的解决流程纵然正当,然而显然代码里的异样解决逻辑有点“喧宾夺主”了。一眼看过来全是代码缩进,很难提炼出代码的外围逻辑。

早在 2.5 版本时,Python 语言就曾经提供了凑合这类场景的工具:“上下文管理器(context manager)”。上下文管理器是一种配合 with 语句应用的非凡 Python 对象,通过它,能够让异样解决工作变得更不便。

那么,如何利用上下文管理器来改善咱们的异样解决流程呢?让咱们间接看代码吧。

在下面的代码里,咱们定义了一个名为 raise_api_error 的上下文管理器,它在进入上下文时什么也不做。然而在退出上下文时,会判断以后上下文中是否抛出了类型为 self.captures 的异样,如果有,就用 APIErrorCode 异样类代替它。

应用该上下文管理器后,整个函数能够变得更清晰简洁:

Hint:倡议浏览 PEP 343 — The “with” Statement | Python.org,理解与上下文管理器无关的更多常识。
模块 contextlib 也提供了十分多与编写上下文管理器相干的工具函数与样例。


总结

在这篇文章中,我分享了与异样解决相干的三个倡议。最初再总结一下要点:

  • 只捕捉可能会抛出异样的语句,防止含混的捕捉逻辑
  • 放弃模块异样类的形象一致性,必要时对底层异样类进行包装
  • 应用“上下文管理器”能够简化反复的异样解决逻辑

看完文章的你,有没有什么想吐槽的?请留言或者在 我的项目 Github Issues 通知我吧。


附录

  • 题图起源: Photo by Bernard Hermant on Unsplash
  • 更多系列文章地址:https://github.com/piglei/one…

系列其余文章:

  • Python 工匠:让函数返回后果的技巧

蓝鲸智云

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

  • 官网:https://bk.tencent.com/
  • 下载链接:https://bk.tencent.com/download/
  • 社区:https://bk.tencent.com/s-mart…
正文完
 0