Python 异常处理浅析

信息安全公益宣传，信息安全知识启蒙。

加微信群回复公众号：微信群；QQ群：16004488

加微信群或QQ群可免费索取：学习教程

教程列表见微信公众号底部菜单

---

异常处理在任何一门编程语言里都是值得关注的一个话题，良好的异常处理可以让你的程序更加健壮，清晰的错误信息更能帮助你快速修复问题。在Python中，和部分高级语言一样，使用了try/except/finally语句块来处理异常，如果你有其他编程语言的经验，实践起来并不难。

什么是异常？

1、错误

从软件方面来说，错误是语法或是逻辑上的。错误是语法或是逻辑上的。

语法错误指示软件的结构上有错误，导致不能被解释器解释或编译器无法编译。这些些错误必须在程序执行前纠正。

当程序的语法正确后，剩下的就是逻辑错误了。逻辑错误可能是由于不完整或是不合法的输入所致；

在其它情况下，还可能是逻辑无法生成、计算、或是输出结果需要的过程无法执行。这些错误通常分别被称为域错误和范围错误。

当python检测到一个错误时，python解释器就会指出当前流已经无法继续执行下去。这时候就出现了异常。

2、异常

对异常的最好描述是：它是因为程序出现了错误而在正常控制流以外采取的行为。

这个行为又分为两个阶段：首先是引起异常发生的错误，然后是检测（和采取可能的措施）阶段。

第一阶段是在发生了一个异常条件（有时候也叫做例外的条件）后发生的。

只要检测到错误并且意识到异常条件，解释器就会发生一个异常。引发也可以叫做触发，抛出或者生成。解释器通过它通知当前控制流有错误发生。

python也允许程序员自己引发异常。无论是python解释器还是程序员引发的，异常就是错误发生的信号。

当前流将被打断，用来处理这个错误并采取相应的操作。这就是第二阶段。

对于异常的处理发生在第二阶段，异常引发后，可以调用很多不同的操作。

可以是忽略错误（记录错误但不采取任何措施，采取补救措施后终止程序。）或是减轻问题的影响后设法继续执行程序。

所有的这些操作都代表一种继续，或是控制的分支。关键是程序员在错误发生时可以指示程序如何执行。

python用异常对象(exception object)来表示异常。遇到错误后，会引发异常。

如果异常对象并未被处理或捕捉，程序就会用所谓的回溯（traceback）终止执行。

异常处理

捕捉异常可以使用try/except语句。

try/except语句用来检测try语句块中的错误，从而让except语句捕获异常信息并处理。

如果你不想在异常发生时结束你的程序，只需在try里捕获它。

语法：

以下为简单的try....except...else的语法：

Try的工作原理是，当开始一个try语句后，python就在当前程序的上下文中作标记，这样当异常出现时就可以回到这里，try子句先执行，接下来会发生什么依赖于执行时是否出现异常。

• 如果当try后的语句执行时发生异常，python就跳回到try并执行第一个匹配该异常的except子句，异常处理完毕，控制流就通过整个try语句（除非在处理异常时又引发新的异常）。

• 如果在try后的语句里发生了异常，却没有匹配的except子句，异常将被递交到上层的try，或者到程序的最上层（这样将结束程序，并打印缺省的出错信息）。

• 如果在try子句执行时没有发生异常，python将执行else语句后的语句（如果有else的话），然后控制流通过整个try语句。

使用except而不带任何异常类型

你可以不带任何异常类型使用except，如下实例：

以上方式try-except语句捕获所有发生的异常。但这不是一个很好的方式，我们不能通过该程序识别出具体的异常信息。因为它捕获所有的异常。

使用except而带多种异常类型

你也可以使用相同的except语句来处理多个异常信息，如下所示：

try-finally 语句

try-finally 语句无论是否发生异常都将执行最后的代码。

当在try块中抛出一个异常，立即执行finally块代码。

finally块中的所有语句执行后，异常被再次触发，并执行except块代码。

参数的内容不同于异常。

下面来看一个实例：

总结如下：

1、except语句不是必须的，finally语句也不是必须的，但是二者必须要有一个，否则就没有try的意义了。

2、except语句可以有多个，Python会按except语句的顺序依次匹配你指定的异常，如果异常已经处理就不会再进入后面的except语句。

3、except语句可以以元组形式同时指定多个异常，参见实例代码。

4、except语句后面如果不指定异常类型，则默认捕获所有异常，你可以通过logging或者sys模块获取当前异常。

5、如果要捕获异常后要重复抛出，请使用raise，后面不要带任何参数或信息。

6、不建议捕获并抛出同一个异常，请考虑重构你的代码。

7、不建议在不清楚逻辑的情况下捕获所有异常，有可能你隐藏了很严重的问题。

8、尽量使用内置的异常处理语句来 替换try/except语句，比如with语句，getattr()方法。

经验案例

传递异常 re-raise Exception
捕捉到了异常，但是又想重新引发它（传递异常），使用不带参数的raise语句即可：

在Python2中，为了保持异常的完整信息，那么你捕获后再次抛出时千万不能在raise后面加上异常对象，否则你的trace信息就会从此处截断。以上是最简单的重新抛出异常的做法。

还有一些技巧可以考虑，比如抛出异常前对异常的信息进行更新。

如果你有兴趣了解更多，建议阅读这篇博客。

• http://www.ianbicking.org/blog/2007/09/re-raising-exceptions.html

Python3对重复传递异常有所改进，你可以自己尝试一下，不过建议还是同上。

Exception 和 BaseException

当我们要捕获一个通用异常时，应该用Exception还是BaseException？我建议你还是看一下 官方文档说明，这两个异常到底有啥区别呢？ 请看它们之间的继承关系。

从Exception的层级结构来看，BaseException是最基础的异常类，Exception继承了它。BaseException除了包含所有的Exception外还包含了SystemExit，KeyboardInterrupt和GeneratorExit三个异常。

有此看来你的程序在捕获所有异常时更应该使用Exception而不是BaseException，因为另外三个异常属于更高级别的异常，合理的做法应该是交给Python的解释器处理。

except Exception as e和 except Exception, e

代码示例如下：

在Python2的时代，你可以使用以上两种写法中的任意一种。在Python3中你只能使用第一种写法，第二种写法被废弃掉了。第一个种写法可读性更好，而且为了程序的兼容性和后期移植的成本，请你也抛弃第二种写法。

raise “Exception string”

把字符串当成异常抛出看上去是一个非常简洁的办法，但其实是一个非常不好的习惯。

上面的语句如果抛出异常，那么会是这样的：

这在Python2.4以前是可以接受的做法，但是没有指定异常类型有可能会让下游没办法正确捕获并处理这个异常，从而导致你的程序挂掉。简单说，这种写法是是封建时代的陋习，应该扔了。

使用内置的语法范式代替try/except

Python 本身提供了很多的语法范式简化了异常的处理，比如for语句就处理的StopIteration异常，让你很流畅地写出一个循环。

with语句在打开文件后会自动调用finally中的关闭文件操作。我们在写Python代码时应该尽量避免在遇到这种情况时还使用try/except/finally的思维来处理。

再比如，当我们需要访问一个不确定的属性时，有可能你会写出这样的代码：

其实你可以使用更简单的getattr()来达到你的目的。

最佳实践

最佳实践不限于编程语言，只是一些规则和填坑后的收获。

1、只处理你知道的异常，避免捕获所有异常然后吞掉它们。

2、抛出的异常应该说明原因，有时候你知道异常类型也猜不出所以然的。

3、避免在catch语句块中干一些没意义的事情。

4、不要使用异常来控制流程，那样你的程序会无比难懂和难维护。

5、如果有需要，切记使用finally来释放资源。

6、如果有需要，请不要忘记在处理异常后做清理工作或者回滚操作。

异常速查表

10个最容易犯的Python开发错误

1、滥用表达式作为函数参数默认值

Python允许开发者指定一个默认值给函数参数，虽然这是该语言的一个特征，但当参数可变时，很容易导致混乱，例如，下面这段函数定义：

在上面这段代码里，一旦重复调用foo()函数（没有指定一个bar参数），那么将一直返回'bar'，因为没有指定参数，那么foo()每次被调用的时候，都会赋予[]。下面来看看，这样做的结果：

解决方案：

2、错误地使用类变量

先看下面这个例子：

这样是有意义的：

再来一遍：

仅仅是改变了A.x，为什么C.x也跟着改变了。

在Python中，类变量都是作为字典进行内部处理的，并且遵循方法解析顺序（MRO）。在上面这段代码中，因为属性x没有在类C中发现，它会查找它的基类（在上面例子中只有A，尽管Python支持多继承）。换句话说，就是C自己没有x属性，独立于A，因此，引用 C.x其实就是引用A.x。

3、为异常指定不正确的参数

假设代码中有如下代码：

问题在这里，except语句并不需要这种方式来指定异常列表。然而，在Python 2.x中，except Exception,e通常是用来绑定异常里的 第二参数，好让其进行更进一步的检查。因此，在上面这段代码里，IndexError异常并没有被except语句捕获，异常最后被绑定 到了一个名叫IndexError的参数上。

在一个异常语句里捕获多个异常的正确方法是指定第一个参数作为一个元组，该元组包含所有被捕获的异常。与此同时，使用as关键字来保证最大的可移植性，Python 2和Python 3都支持该语法。

4、误解Python规则范围

Python的作用域解析是基于LEGB规则，分别是Local、Enclosing、Global、Built-in。实际上，这种解析方法也有一些玄机，看下面这个例子：

许多人会感动惊讶，当他们在工作的函数体里添加一个参数语句，会在先前工作的代码里报UnboundLocalError错误（ 点击这里查看更详细描述）。

在使用列表时，开发者是很容易犯这种错误的，看看下面这个例子：

为什么foo2失败而foo1运行正常？

答案与前面那个例子是一样的，但又有一些微妙之处。foo1没有赋值给lst，而foo2赋值了。lst += [5]实际上就是lst = lst + [5]，试图给lst赋值（因此，假设Python是在局部作用域里）。然而，我们正在寻找指定给lst的值是基于lst本身，其实尚未确定。

5、修改遍历列表

下面这段代码很明显是错误的：

在遍历的时候，对列表进行删除操作，这是很低级的错误。稍微有点经验的人都不会犯。

对上面的代码进行修改，正确地执行：

6、如何在闭包中绑定变量

看下面这个例子：

你期望的结果是：

实际上：

是不是非常吃惊！出现这种情况主要是因为Python的后期绑定行为，该变量在闭包中使用的同时，内部函数又在调用它。

解决方案：

7、创建循环模块依赖关系

假设有两个文件，a.py和b.py，然后各自导入，如下：

在a.py中：

在b.py中：

首先，让我们试着导入a.py：

可以很好地工作，也许你会感到惊讶。毕竟，我们确实在这里做了一个循环导入，难道不应该有点问题吗？

仅仅存在一个循环导入并不是Python本身问题，如果一个模块被导入，Python就不会试图重新导入。根据这一点，每个模块在试图访问函数或变量时，可能会在运行时遇到些问题。

当我们试图导入b.py会发生什么（先前没有导入a.py）：

出错了，这里的问题是，在导入b.py的过程中还要试图导入a.py，这样就要调用f()，并且试图访问b.x。但是b.x并未被定义。

可以这样解决，仅仅修改b.py导入到a.py中的g()函数：

无论何时导入，一切都可以正常运行：

8、与Python标准库模块名称冲突

Python拥有非常丰富的模块库，并且支持“开箱即用”。因此，如果不刻意避免，很容易发生命名冲突事件。例如，在你的代码中可能有一个email.py的模块，由于名称一致，它很有可能与Python自带的标准库模块发生冲突。

9、未按规定处理Python2.x和Python3.x之间的区别

看一下foo.py：

在Python 2里面可以很好地运行：

但是在Python 3里：

解决方案：

在Py3k中运行结果：

在 Python招聘指南里有许多关于Python 2与Python 3在移植代码时需要关注的注意事项与讨论，大家可以前往看看。

10、滥用__del__方法

比如这里有一个叫mod.py的文件：

下面，你在another_mod.py文件里执行如下操作：

你会获得一个AttributeError异常。

当解释器关闭时，该模块的全局变量全部设置为None。因此，在上面这个例子里，当__del__被调用时，foo已经全部被设置为None。

一个很好的解决办法是使用atexit.register()代替。顺便说一句，当程序执行完成后，您注册的处理程序会在解释器关闭之前停止 工作。

修复上面问题的代码：

在程序的正常终止的前提下，这个实现提供了一个整洁可靠的方式调用任何需要清理的功能。

总结

Python是一款强大而灵活的编程语言，并且带有许多机制和模式来大大提高工作效率。正如任何一门语言或软件工具一样，人们对其能力都会存在一个限制性地理解或欣赏，有些是弊大于利，有些时候反而会带来一些陷阱。