10.3　检测和处理异常

异常可以通过try语句来检测。任何在try语句块里的代码都会被监测，检查有无异常发生。

try语句有两种主要形式：try-except和try-finally。这两个语句是互斥的，也就是说你只能使用其中的一种。一个try语句可以对应一个或多个except子句，但只能对应一个finally子句，或是一个try-except-finally复合语句。

你可以使用try-except语句检测和处理异常。你也可以添加一个可选的else子句处理没有探测到异常的执行的代码。而try-finally只允许检测异常并做一些必要的清除工作（无论发生错误与否），没有任何异常处理设施。正如你想像的，复合语句两者都可以做到。

10.3.1　try-except语句

try-except语句（以及其更复杂的形式）定义了进行异常监控的一段代码，并且提供了处理异常的机制。

最常见的try-except语句语法如下所示。它由try块和except块（try_suite和except_suite）组成，也可以有一个可选的错误原因。

我们用一个例子说明这一切是如何工作的。我们将使用上边的IOError例子，把我们的代码封装在try-except里，让代码更健壮：

如你所见，我们的代码运行时似乎没有遇到任何错误。事实上我们在尝试打开一个不存在的文件时仍然发生了 IOError。有什么区别么？我们加入了探测和错误错误的代码。当引发IOError异常时，我们告诉解释器让它打印出一条诊断信息。程序继续执行，而不像以前的例子那样被“轰出来”——异常处理小小地显了下身手。那么在代码方面发生了什么呢？

在程序运行时，解释器尝试执行try块里的所有代码，如果代码块完成后没有异常发生，执行流就会忽略except语句继续执行。而当except语句所指定的异常发生后，我们保存了错误的原因，控制流立即跳转到对应的处理器（try子句的剩余语句将被忽略），本例中我们显示出一个包含错误原因的错误信息。

在我们上边的例子中，我们只捕获IOError异常。任何其他异常不会被我们指定的处理器捕获。举例说，如果你要捕获一个OSError,你必须加入一个特定的异常处理器。我们将在本章后面详细地介绍try-except语法。

核心笔记：忽略代码，继续执行’和向上移交

try语句块中异常发生点后的剩余语句永远不会到达（所以也永远不会执行）。一旦一个异常被引发，就必须决定控制流下一步到达的位置。剩余代码将被忽略，解释器将搜索处理器，一旦找到，就开始执行处理器中的代码。

如果没有找到合适的处理器，那么异常就向上移交给调用者去处理，这意味着堆栈框架立即回到之前的那个。如果在上层调用者也没找到对应处理器，该异常会继续被向上移交，直到找到合适处理器。如果到达最顶层仍然没有找到对应处理器，那么就认为这个异常是未处理的，Python解释器会显示出跟踪记录，然后退出。

10.3.2　包装内建函数

我们现在给出一个交互操作的例子——从最基本的错误检测开始，然后逐步改进它，增强代码的健壮性。这里的问题是把一个用字符串表示的数值转换为正确的数值表示形式，而且在过程中要检测并处理可能的错误。

float()内建函数的基本作用是把任意一个数值类型转换为一个浮点型。从Python 1.5开始，float()增加了把字符串表示的数值转换为浮点型的功能，没必要使用string模块中的atof()函数。如果你使用的老版本的Python,请使用string.atof()替换这里的float()。

不幸的是, float()对输入很挑剔：

从上面的错误我们可以看出，float()对不合法的参数很不客气。例如，如果参数的类型正确（字符串），但值不可转换为浮点型，那么将引发ValueError异常，因为这是值的错误。列表也是不合法的参数，因为他的类型不正确，所以引发一个TypeError异常。

我们的目标是“安全地”调用float()函数，或是使用一个“安全的方式”忽略掉错误，因为它们与我们转换数值类型的目标没有任何联系，而且这些错误也没有严重到要让解释器终止执行。为了实现我们的目的，这里我们创建了一个“封装”函数，在try-except的协助下创建我们预想的环境，我们把他叫做safe_float()。在第一次改进中我们搜索并忽略ValueError,因为这是最常发生的。而TypeError并不常见，我们一般不会把非字符串数据传递给float()。

我们采取的第一步只是“止血”。在上面的例子中，我们把错误“吞了下去”。换句话说，错误会被探测到，而我们在except从句里没有放任何东西（除了一个pass，这是为了语法上的需要），不进行任何处理，忽略这个错误。

这个解决方法有一个明显的不足，它在出现错误的时候没有明确地返回任何信息。虽然返回了 None（当函数没有显式地返回一个值时，例如没有执行到return object语句函数就结束了，它就返回None）,我们并没有得到任何关于出错信息的提示。我们至少应该显式地返回None,来使代码更容易理解：

注意我们刚才做的修改，我们只是添加了一个局部变量。在有设计良好的应用程序接口（ApplicationProgrammer Interface, API）时，返回值可以更灵活。你可以在文档中这样写，如果传递给safe_float()合适的参数，它将返回一个浮点型；如果出现错误，将返回一个字符串说明输入数据有什么问题。我们按照这个方案再修改一次代码，如下所示：

这里我们只是把None替换为一个错误字符串。下面我们试试这个函数看看它表现如何：

我们有了一个好的开始——现在我们已经可以探测到非法的字符串输入了，可如果传递的是一个非法的对象，还是会“受伤”：

我们暂时只是指出这个缺点，在进一步改进程序之前，首先来看看try-except的其他灵活的语法，特别是except语句，它有好几种变化形式。

10.3.3　带有多个except的try语句

在本章的前边，我们已经介绍了except的基本语法：

这种格式的except语句指定检测名为Exception的异常。你可以把多个except语句连接在一起，处理一个try块中可能发生的多种异常，如下所示：

同样，首先尝试执行try子句，如果没有错误，忽略所有的except从句继续执行。如果发生异常，解释器将在这一串处理器（except子句）中查找匹配的异常如果找到对应的处理器，执行流将跳转到这里。

我们的safe_float()函数已经可以检测到指定的异常了。更聪明的代码能够处理好每一种异常。这就需要多个except语句，每个except语句对应一种异常类型。Python支持把except语句串连使用我们将分别为每个异常类型分别创建对应的错误信息，用户可以得到更详细的关于错误的信息：

使用错误的参数调用这个函数，我们得到下面的输出结果：

10.3.4　处理多个异常的 except语句

我们还可以在一个except子句里处理多个异常。except语句在处理多个异常时要求异常被放在一个元组里：

上边的语法展示了如何处理同时处理两个异常。事实上except语句可以处理任意多个异常，前提只是它们被放入一个元组里，如下所示：

如果由于其他原因，也许是内存规定或是设计方面的因素，要求safe_float()函数中的所有异常必须使用同样的代码处理，那么我们可以这样满足需求：

现在，错误的输入会返回相同的字符串：

10.3.5　捕获所有异常

使用前一节的代码，我们可以捕获任意数目的指定异常，然后处理它们。如果我们想要捕获所有的异常呢？当然可以!自版本1.5后，异常成为类，实现这个功能的代码有了很大的改进。也因为这点（异常成为类），我们现在有一个异常继承结构可以遵循。

如果查询异常继承的树结构，我们会发现Exception是在最顶层的，所以我们的代码可能看起来会是这样：

另一个我们不太推荐的方法是使用空except子句：

这个语法不如前个“Pythonic”。虽然这样的代码捕获大多异常，但它不是好的Python编程样式。一个主要原因是它不会考虑潜在的会导致异常的主要原因。我们的catch-all语句可能不会如你所想的那样工作，它不会调查发生了什么样的错误，如何避免它们。

我们没有指定任何要捕获的异常——这不会给我们任何关于可能发生的错误的信息。另外它会捕获所有异常，你可能会忽略掉重要的错误，正常情况下这些错误应该让调用者知道并做一定处理。最后，我们没有机会保存异常发生的原因。当然，你可以通过sys.exc_info()获得它，但这样你就不得不去导入sys模块，然后执行函数——这样的操作本来是可以避免的，尤其当我们需要立即告诉用户为什么发生异常的时候。在Python的未来版本中很可能不再支持空except子句（参见“核心风格”）。

关于捕获所有异常，你应当知道有些异常不是由于错误条件引起的。它们是SystemExit和KeyboardInterupt。 SystemExit是由于当前Python应用程序需要退出，KeyboardInterupt代表用户按下了 CTRL-C （^C）,想要关闭Python。在真正需要的时候，这些异常却会被异常处理捕获。一个典型的迂回工作法代码框架可能会是这样：

关于异常的一部分内容在Python2.5有了一些变化。异常被迁移到了新式类（new-style class）上，启用了一个新的“所有异常之母”，这个类叫做BaseException,异常的继承结构有了少许调整，为了让人们摆脱不得不除创建两个处理器的惯用法。KeyboardInterrupt和SystemExit被从Exception里移出和 Exception平级：

你可以在表10.2找到整个异常继承结构（变化前后）。

这样，当你已经有了一个Exception处理器后，你不必为这两个异常创建额外的处理器。代码将会是这样：

如果你确实需要捕获所有异常，那么你就得使用新的BaseException:

当然，也可以使用不被推荐的空except子句。

核心风格：不要处理并忽略所有错误

Python提供给程序员的try-except语句是为了更好地跟踪潜在的错误并在代码里准备好处理异常的逻辑。这样的机制在其他语言（例如C）是很难实现的。它的目的是减少程序出错的次数并在出错后仍能保证程序正常执行。作为一种工具而言，只有正确得当地使用它，才能使其发挥作用。

一个不正确的使用方法就是把它作为一个大绷带“绑定”到一大片代码上。也就是说把一大段程序（如果还不是整个程序源代码的话）放入一个try块中，再用一个通用的except语句“过滤”掉任何致命的错误，忽略它们。

很明显，错误无法避免，try-except的作用是提供一个可以提示错误或处理错误的机制，而不是一个错误过滤器。上边这样的结构会忽略许多错误，这样的用法是缺乏工程实践的表现，我们不赞同这样做。

底线：避免把大片的代码装入try-except中然后使用pass忽略掉错误。你可以捕获特定的异常并忽略它们，或是捕获所有异常并采取特定的动作。不要捕获所有异常，然后忽略掉它们。

10.3.6　“异常参数”

异常也可以有参数，异常引发后它会被传递给异常处理器。当异常被引发后参数是作为附加帮助信息传递给异常处理器的。虽然异常原因是可选的，但标准内建异常提供至少一个参数，指示异常原因的一个字符串。

异常的参数可以在处理器里忽略，但Python提供了保存这个值的语法。我们已经在上边接触到相关内容：要想访问提供的异常原因，你必须保留一个变量来保存这个参数。把这个参数放在except语句后，接在要处理的异常后面。except语句的这个语法可以被扩展为：

reason将会是一个包含来自导致异常的代码的诊断信息的类实例。异常参数自身会组成一个元组，并存储为类实例（异常类的实例）的属性。上边的第一种用法中，reason将会是一个Exception类的实例。

对于大多内建异常，也就是从StandardError派生的异常，这个元组只包含一个指示错误原因的字符串。一般说来，异常的名字已经是一个满意的线索了，但这个错误字符串会提供更多的信息。操作系统或其他环境类型的错误，例如IOError,元组中会把操作系统的错误编号放在错误字符串前。

无论reason只包含一个字符串或是由错误编号和字符串组成的元组，调用str （reason）总会返回一个良好可读的错误原因。不要忘记reason是一个类实例——这样做你其实是调用类的特殊方法str()。我们将在第13章探索面向对象编程中的这些特殊方法。

唯一的问题就是某些第三方或是其他外部库并不遵循这个标准协议。我们推荐你在引发你自己的异常时遵循这个标准（参见核心风格）。

核心风格：遵循异常参数规范

当你在自己的代码中引发内建 （built-in）的异常时，尽量遵循规范，用和已有Python代码一致错误信息作为传给异常的参数元组的一部分。简单地说，如果你引发一个ValueError,那么最好提供和解释器引发ValueError时一致的参数信息，以此类推。这样可以在保证代码一致性，同时也能避免其他应用程序在使用你的模块时发生错误。

如下边的例子，它传参给内建float函数一个无效的对象，引发TypeError异常：

我们首先在一个try语句块中引发一个异常，随后简单的忽略了这个异常，但保留了错误的信息。调用内置的type()函数，我们可以确认我们的异常对象的确是TypeError异常类的实例。最后我们对异常诊断参数调用print以显示错误。

为了获得更多的关于异常的信息，我们可以调用该实例的class属性，它标示了实例是从什么类实例化而来。类对象也有属性，比如文档字符串（documentation string）和进一步阐明错误类型的名称字符串：

我们会在第13章中发现，class属性存在于所有的类实例中，而doc类属性存在于所有的定义了文档字符串的类中。

我们现在再次来改进我们的saft_float()以包含异常参数，当float()发生异常时传给解释器。在前一次改进中，我们在一句话中同时捕获了 ValueError和TypeError异常以满足某些需求。但还是有瑕疵，那个解决方案中没有线索表明是哪一种异常引发了错误。它仅仅是返回了一个错误字符串指出有无效的参数。现在，通过异常参数可以改善这种状况。

因为每一个异常都将生成自己的异常参数，如果我们选择用这个字符串来而不是我们自定义的信息，可以提供一个更好的线索来指出问题。下面的代码片段中，我们用字符串化（string representation）的异常参数来替换单一的错误信息。

在此基础上运行我们的新代码，当我们提供safe_float()的参数给不恰当时，虽然还是只有一条捕获语句，但是可以获得如下（不同的）信息。

10.3.7　在应用使用我们封装的函数

我们将在一个迷你应用中特地的使用这个函数。它将打开信用卡交易的数据文件（carddata.txt）,加载所有的交易，包括解释的字符串。下面是一个示例的carddate.txt文件：

我们的程序cardrun.py见例10.1。

例10.1　信用卡交易系统（cardrun.py）

我们用safe_float()来处理信用卡交易文件，将其作为字符串读入。并用一个日志文件跟踪处理进程。

逐行解释

3 ~ 9行

这段代码是safe_float()函数的主体。

11 ~ 34行

我们应用的核心部分有3个主要任务：

（1）读入信用卡的数据文件；

（2）处理输入；

（3）显示结果。

14 ~ 22行

从文件中提取数据。你可以看到这里的文件打开被置于try-except语句段中。

同时还有一个处理的日志文件。在我们的例子中，我们假设这个日志文件可以不出错的打开。你可以看到我们的处理进程伴随着这个日志文件。如果信用卡的数据文件不能够被访问，我们可以假设该月没有信用卡交易（行16~19）。

数据被读入txns （transactions交易）列表，随后在26〜32行遍历它。每次调用safe_float()后，我们用内建的isinstance函数检查结果类型。在我们例子中，我们检查safe_float是返回字符串还是浮点型。任何字符串都意味着错误，表明该行不能转换为数字，同时所有的其他数字可以作为浮点型累加入total。在main()函数的尾行会显示最终生成的余额。

36 ~ 37行

这两行通常表明“仅在非导入时启动”的功能。运行我们程序，可以得到如下的输出。

我们再看看log文件（cardlog.txt）,我们可以看到在处理完carddata.txt中的交易后有其有如下的记录条目：

10.3.8　else子句

我们已经看过else语句段配合其他的Python语句，比如条件和循环。至于try-except语句段，它的功能和你所见过的其他else没有太多的不同：在try范围中没有异常被检测到时，执行else子句。

在else范围中的任何代码运行前，try范围中的所有代码必须完全成功（也就是，结束前没有引发异常）。下面是用Python伪代码写的简短例子。

在前面的例子中，我们导入了一个外部的模块然后测试是否有错误。用一个日志文件来确定这个第三方模块是有无缺陷。根据运行时是否引发异常，我们将在日志中写入不同的消息。

10.3.9　finally子句

finally子句是无论异常是否发生，是否捕捉都会执行的一段代码。你可以将finally仅仅配合try一起使用，也可以和try-except （else也是可选的）一起使用。独立的try-finally将会在下一章介绍，我们稍后再来研究。

从Python 2.5开始，你可以用finally子句（再一次）与try-except或try-except-else—起使用。之所以说是“再一次”是因为无论你相信与否，这并不是一个新的特性。回顾Python初期，这个特性早已存在，但是在Python 0.9.6（1992 4月）中被移除。那时，这样可以简化字节码的生成，并方便解析，另外van Rossum认为一个标准化的try-except（-else）-finally无论如何不会太流行。然而，十年时间改变了一切！

下面是try-except-else-finally语法的示例：

等价于Python 0.9.6至 2.4.x中如下的写法：

当然，无论如何，你都可以有不止一个的except子句，但最少有一个except语句，而else和finally都是可选的。A、B、C和D是程序（代码块）。程序会按预期的顺序执行。（注意：可能的顺序是A-C-D[正常]或A-B-D[异常]）。无论异常发生在Α、Β和/或C都将执行finally块。旧式写法依然有效，所以没有向后兼容的问题。

10.3.10　try-finally语句

另一种使用finally的方式是finally单独和try连用。这个try-finally语句和try-except区别在于它不是用来捕捉异常的。作为替代，它常常用来维持一致的行为而无论异常是否发生。我们得知无论try中是否有异常触发，finally代码段都会被执行。

当在try范围中产生一个异常时，（这里）会立即跳转到finally语句段。当finally中的所有代码都执行完毕后，会继续向上一层引发异常。

因而常常看到嵌套在try-except中的try-finally语句。当在读取carddata.txt中文本时可能引发异常，我们可以在cardrun.py的这一处添加try-finally语句段来改进代码。在当前示例10.1的代码中，我们在读取阶段没有探测到错误（通过readlines()）。

但有很多原因会导致readlines()失败，其中一种就是carddata.txt存在于网络（或软盘）上，但是变得不能读取。无论怎样，我们可以把这一小段读取数据的代码整个放入try子句的范围中：

我们所做的一切不过是将readline()和close()方法调用都移入了try语句段。尽管我们代码变得更加的健壮了，但还有改进的空间。注意如果按照这样的顺序发生错误：打开成功，但是出于一些原因readlines()调用失败，异常处理会去继续执行except中的子句，而不去尝试关闭文件。难道没有一种好的方式来关闭文件而无论错误是否发生?我们可以通过try-finally来实现：

代码片段会尝试打开文件并且读取数据。如果在其中的某步发生一个错误，会写入日志，随后文件被正确的关闭。如果没有错误发生，文件也会被关闭（同样的功能可以通过上面标准化的try-except-finally语句段实现）。另一种可选的实现切换了try-except和try-finally包含的方式，如：

代码本质上千的是同一种工作，除了一些小小的不同。最显著的是关闭文件发生在异常处理器将错误写入日志之前。这是因为finally会自动的重新引发异常。

这样写的一个理由是如果在finally的语句块内发生了一个异常，你可以创建一个同现有的异常处理器在同一个（外）层次的异常处理器来处理它。这样，从本质上来说，就可以同时处理在原始的try语句块和finally语句块中发生的错误。这种方法唯一的问题是，当finally语句块中的确发生异常时，你会丢失原来异常的上下文信息，除非你在某个地方保存了它。

反对这种写法的一个理由是：在很多情况下，异常处理器需要做一些扫尾工作，而如果你在异常处理之前，用finally语句块中释放了某些资源，你就不能再去做这项工作了。简单地说，finally语句块并不是如你所想的是“最终的（final）”了。

一个最终的注意点：如果finally中的代码引发了另一个异常或由于return、break、continue语法而终止，原来的异常将丢失而且无法重新引发。

10.3.11　try-except-else-finally：厨房一锅端

我们综合了这一章目前我们所见过的所有不同的可以处理异常的语法样式：

回顾上面，finally子句和try-except或try-except-else联合使用是Python 2.5的“新”有的。这一节最重要的是无论你选择什么语法，你至少要有一个except子句，而else和finally都是可选的。