转载

Python中最糟糕的代码模式

下文是Aaron Maxwell投递的客座博文，他是Advanced Python Newsletter的作者。

错误代码千千万，在Python中，有一种是最糟糕的。

在其他两位工程师每人花费三天的时间试图去搞定一个Unicode编码的“玄学”问题而徒劳无功后，我仅仅花费了一天时间就定位到了错误的子句，尽管很累，但是很开心。十分钟后，我们就有了应对该bug的方法。

我们本可以用十分钟而不是宝贵的七天来解决这个问题，这样的事实让我们很痛苦。当然，这样说也有点鲁莽……

下面的这段代码就是关键点，这一小段代码是Python开发者能够写出来的最具有自我毁灭性的代码片段之一：

Python中最糟糕的代码模式

这一段代码还有很多其他的写法，如“except Exception:”或者“except Exception as e”，这给后续的工作带来了很大的麻烦：忽略和隐藏了错误的发生，并且不给出任何提示，否则在一般情况下类似的问题是很容易解决的。

为什么我说这段代码是当今Python世界中最可怕的代码呢？

人们写这段话是因为知道这里发生某种特定类型的异常，然而，捕获异常后却忽略所有的错误……甚至是那些不可预料的异常。
当这个bug出现时——经常出现，因为生产环境中总是有这样的代码——你可能都不知道代码库的哪部分出现了错误。这可能会耗费上好几小时沮丧的时光去才能发现错误竟然是出现在try语句块中。
就算你发现了错误，在你想要解决问题时，却发现缺少必要的提示信息。这个错误/异常的类型是什么？涉及到哪些调用和数据接口？错误最开始出现在哪一个文件的哪一行代码？
更糟糕的是，这很有可能伤害到在当前代码上工作的工程师的士气，乐趣甚至是自尊。错误出现时，故障排查人员可能需要花费几个小时去理解代码。他们会觉得自己是个糟糕的码农，因为他们需要几个小时才能找到错误。事实上并不是。捕获了异常而又对错误放任不管，这样的问题很难定位，排除，修复。

无论是独自工作还是作为团体中一份子，在我作为Python民工的十年开发经历中，这是我遇到的最能够打击士气，降低生产力和应用可靠性的代码片段，如果你有其他更厉害的代码，欢迎讨论。

我们为什么会写出这样的代码？

当然，没有人故意写这样的代码给团队成员增加压力和破坏应用的可靠性。我们之所以写这个是因为在try语句块中，代码在某些特定情况下可能会执行失败。乐观地进行尝试并且捕获异常是解决这种问题的一种很优秀，很Python的做法。

更阴险的是，去捕获异常，然后不报出任何对应的处理并不是这个可怕的想法中最糟糕的时候，然而，当你按下保存按钮时，你就将你的代码处于“万劫不复”的深渊：

Bugs能够在开发过程中避免被发现地命运，最终会被推送到实际生产环境中。
当你发现bug的存在之前，它可能已经存活了数分钟，数小时，数天甚至是数周。
这样的bug很难定位。
即使你知道哪里会出现异常，你也很难去修复这个bug。

注意，我并不是说不去捕获异常。有很多必需的理由去捕获异常并进行处理，但就是千万不要让它静悄悄地溜走。比如当你处理一项至关重要的事务时，你甚至不想让它简单地执行完就算了，比较明智的做法是插入try语句来捕获异常，并把相应的堆栈追踪信息记录使用logging.ERROR记录下来，然后再继续执行。

解决之道

所以如果你不想捕获范围太宽广的异常，有什么替代的办法呢？有两种选择。

在大多数情况下，最好建议你去捕获更加特定的异常，如：

Python中最糟糕的代码模式

这是你首先应当做的尝试。它需要你对相关的代码有一些了解，如此才可能推断出会发生什么类型的异常。当你是第一次写自己的代码时，这种方法还是比较简单的。不过当清理别人代码时，这就会让你痛苦万分的。

如果有些代码需要捕获所有的异常，如在顶层循环中长时间运行的程序，捕获的每个异常需要把相关的堆栈追踪信息写入日志或者文件，同时要有相应的时间戳。如果你是使用Python的logging模块，做起来时非常简单的，每个logger对象都有叫exception的方法，它接受一个字符串做参数。如果你在异常捕获的时候调用这个方法，捕获的异常连同堆栈追踪信息都会被自动记录下来。

Python中最糟糕的代码模式

这个日志包含错误信息，后面几行是堆栈追踪信息。

Python中最糟糕的代码模式

歪瑞一贼！

如果你的应用程序并不是使用logging模块来进行记录呢？假设你不想重构你的代码，你仅仅需要找到异常语句，并对堆栈追踪信息进行格式化输出。在Python3里很容易做到的。

Python中最糟糕的代码模式

在Python2中，你再多做一丢丢工作就好了：因为exception对象没有相对应的堆栈追踪信息。你可以在except语句块中调用sys.exc_info()函数来实现。

Python中最糟糕的代码模式

正如你所看到的，你可以把上述两种代码中的traceback-logging函数进行整合，从而可以忽略你是在Python2还是Python3下工作。

Python中最糟糕的代码模式

挽救措施

“好的吧，Aaron，你成功说服了我。我为我过去做的蠢事而流泪悔恨。我现在能做点什么补救措施？”我很高兴你这样问，下面的一些方法你可以尝试一下。

在你的编程规范中明确地制止它

如果你的团队有代码评审这一环节，你们应该会有代码编写的指导手册。如果没有，也很容易创建——就跟新建一个wiki页面一样。你需要把以下两条建议加入：

如果有些代码需要捕获所有的异常，如在顶层中长时间运行的程序语句，那么每个捕获的异常都需要将其相关的堆栈追踪信息记录下来，包括时间戳。不仅仅是异常的类型和信息，也包括整个的追踪信息。
对于其他的大多数异常来说，尽可能捕获精确类型的异常，如值错误，连接超时等。

为已经存在的except字句列清单

上面的方法能够帮助你避免未来的错误。然而已经存在的异常捕捉过广的except语句怎么办？很简单：在bug追踪系统中列出 except 字句清单，然后去一个个地修复它们。这是简单且有效的解决问题的办法。你可以现在就着手去做。

我建议你为每一个仓库或应用去建立清单，在你的代码中找到每个Exception，然后去优化它（你只需要在代码库通过检索找出“except”和 “except Exception”）。你可以把它转换成处理某种特定类型的异常，或者如果你对代码不清楚的话，修改except语句去记录堆栈追踪信息。

你还可以进一步优化，为需要指定特定类型的异常建立一个清单。如果感到这个异常可以更加精确时，但是你对代码的内部结构不清楚时可以这样做。在这种情况下，你需要记录该异常的堆栈追踪信息；单独为此创建一个清单来记录；把它委派到某个对代码更加了解的家伙手里。如果你在单个的try/except中花费超过 5分钟的时间去思考找出一个特定的异常时，我推荐你这样做。