Python官方中文教程(转) 6

Python官方中文教程(转) 6
转自 Python官方中文教程 第六章：错误异常

---

1. 什么是异常？

在程序运行过程中，总会遇到各种各样的问题和错误。

有些错误是我们编写代码时自己造成的，比如语法错误、调用错误，甚至逻辑错误。下面这个例子，在输入if后输入回车了，没有按照 Python 的语法规则来，所以直接抛出了语法错误。

>>> if
  File "<stdin>", line 1
    if
     ^
SyntaxError: invalid syntax

还有一些错误，则是不可预料的错误，但是完全有可能发生的，比如文件不存在、磁盘空间不足、网络堵塞、系统错误等等。下面这个例子，使用 open函数打开 demo.txt文件，可是在当前目录下并没有这个文件，所以一定会打开失败，抛出了IOError。

>>> fp = open('demo.txt')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'demo.txt'

这些导致程序在运行过程中出现异常中断和退出的错误，我们统称为异常。正常情况下，异常都不会被程序处理，而是以错误信息的形式展现出来。

异常有很多种类型，Python内置了几十种常见的异常，就在builtins模块内，它们无需特别导入，就可以直接使用。需要注意的是，所有的异常都是异常类，首字母是大写的！

在发生异常的时候，Python会打印出异常信息，信息的前面部分显示了异常发生的上下文环境，并以调用栈的形式显示具体信息。异常类型作为信息的一部分也会被打印出来，例如ZeroDivisionError，TypeError。

>>> 1/0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero
>>>
>>>
>>> 10 + "1"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

正常情况下，我们都不需要去记住 Python 到底内置了哪些错误和异常类型，除非你需要去捕获它，关于捕获的内容，我会放在下一节。这一节先来认识一下 Python 中有哪些常见的错误和异常，对于新手，下面的内容大概过一下就好，不用深究，因为这些在你以后的编码中都会遇到的。

---

1.1 SyntaxError

SyntaxError，是语法错误，可能是新手在学习 Python 时最容易遇到的错误

>>> while True print('Hello world')
  File "<stdin>", line 1
    while True print('Hello world')
                   ^
SyntaxError: invalid syntax

解析器会输出出现语法错误的那一行，并显示一个“箭头”，指向这行里面检测到的第一个错误。 错误是由箭头指示的位置 上面 的 token 引起的（或者至少是在这里被检测出的）：在示例中，在print()https://docs.python.org/zh-cn/3/library/functions.html#print__ 这个函数中检测到了错误，因为在它前面少了个冒号 (’:’) 。文件名和行号也会被输出，以便输入来自脚本文件时你能知道去哪检查。

---

1.2 TypeError

TypeError，是类型错误，也就是说将某个操作或功能应用于不合适类型的对象时引发，比如整型与字符型进行加减法

>>> a = 10
>>> b = "1"
>>>
>>> a-b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for -: 'int' and 'str'

---

1.3 IndexError

IndexError，是指索引出现了错误，比如最常见下标索引超出了序列边界

>>> alist = [0,1,2]
>>> alist[5]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list index out of range

---

1.4 KeyError

KeyError是关键字错误，这个异常主要发生在字典中，比如当用户试图访问一个字典中不存在的键时会被引发。

>>> profile = {"name": "王炳明"}
>>> profile["age"]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'age'

---

1.5 ValueError

ValueError为值错误，当用户传入一个调用者不期望的值时会引发，即使这个值的类型是正确的，比如想获取一个列表中某个不存在值的索引。

>>> int("1")
1
>>> int("a")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: 'a'

---

1.6 AttributeError

AttributeError是属性错误，当用户试图访问一个对象不存在的属性时会引发。

比如字典有get方法，而列表却没有，所以对一个列表对象调用该方法就会引发该异常。

>>> alist = [0,1,2]
>>> alist.get(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'list' object has no attribute 'get'

---

1.7 NameError

NameError是指变量名称发生错误，比如用户试图调用一个还未被赋值或初始化的变量时会被触发。

>>> name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'name' is not defined

---

1.8 IOError

IOError为打开文件错误，当用户试图以读取方式打开一个不存在的文件时引发。

>>> fb = open('demo.txt')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'demo.txt'

---

1.9 StopIteration

StopIteration为迭代器错误，当访问至迭代器最后一个值时仍然继续访问，就会引发这种异常，提醒用户迭代器中已经没有值可供访问了。

>>> alist = range(2)
>>> agen = iter(alist)
>>> next(agen)
0
>>> next(agen)
1
>>> next(agen)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

---

1.10 AssertionError

AssertionError为断言错误，当用户利用断言语句检测异常时，如果断言语句检测的表达式为假，则会引发这种异常。

>>> alist = [0,1,2]
>>> assert isinstance(alist, list)
>>> assert isinstance(alist, dict)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError

---

1.11 IndentationError

Python 是一门严格缩进的语言，如果缩进有问题，就会导致解释器解析异常，抛出IndentationError

>>> while True:
... print("hello")
  File "<stdin>", line 2
    print("hello")
        ^
IndentationError: expected an indented block

---

1.12 ImportError

当你在使用 import导包的时候，如果因为包名错误或者路径不对、包未安装，都会抛出 ImportError

>>> import oxx
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named oxx

上面这些异常应该是平时编程中遇见频率比较高的一部分，还有更多的异常，可以前往官方文档：https://docs.python.org/3/library/exceptions.html

---

2. 如何抛出和捕获异常

2.1 如何抛出异常？

异常的产生有两种来源：

一种是程序自动抛出，比如1/0会自动抛出 ZeroDivisionError
一种是开发者主动抛出，使用raise关键字抛出。
在 Python 中是使用 raise关键字来抛出异常的，比如在下面这个函数中，如果不存在目标文件，则会抛出一个 Exception通用异常。

def demo_func(filename):
    if not os.path.isfile(filename):
        raise Exception
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">

2.2 如何捕获异常？

出现错误或者异常没有关系，关键在于你要学会预判程序可能会出现的错误或异常，然后在代码中捕获这些异常并处理。

异常的捕获的语法有如下四种：

第一种语法

只捕捉但是不想获取异常信息

try:
    代码A
except [EXCEPTION]:
    代码B

第二种语法

不但捕捉了还要获取异常信息，赋值给 e后，后面你可以把异常信息打印到日志中。

try:
    代码A
except [EXCEPTION] as e:
    代码B

有了上面的基础语法，可以扩展出下面三种常用的异常捕获的写法。

第三种语法

正常使用try ... except ...

如果代码A发生了异常，则会走到代码B的逻辑。

try:
    代码A
except [exception] as e :
    代码B

举个例子

>>> try:
...     1/0
... except ZeroDivisionError as e:
...     print("发生了异常：错误信息如下: \n" + str(e))
...
发生了异常：错误信息如下:
integer division or modulo by zero

第四种语法

使用try ... except ... else

如果代码A发生了异常，则会走到代码B的逻辑，如果没有发生异常，则会走到代码C

try:
    代码A
except [exception] as e:
    代码B
else:
    代码C

举个例子

不发生异常的情况

>>> try:
...     4/2
... except ZeroDivisionError as e:
...     print("发生了异常：错误信息如下: \n" + str(e))
... else:
...     print("程序正常运行")
...
2
程序正常运行

发生异常的情况

>>> try:
...     1/0
... except ZeroDivisionError as e:
...     print("发生了异常：错误信息如下: \n" + str(e))
... else:
...     print("程序正常运行")
...
发生了异常：错误信息如下:
integer division or modulo by zero

第三种：使用 try ... except ... finally
如果代码A发生了异常，则会走到代码B的逻辑，最后不管有没有发生异常都会走到代码C

try:
    代码A
except [exception] as e:
    代码B
finally:
    代码C

举个例子

发生异常的情况

>>> try:
...     1/0
... except ZeroDivisionError as e:
...     print("发生了异常：错误信息如下: \n" + str(e))
... finally:
...     print("程序运行结束!!")
...
发生了异常：错误信息如下:
integer division or modulo by zero
程序运行结束!!

不发生异常的情况

>>> try:
...     4/2
... except ZeroDivisionError as e:
...     print("发生了异常：错误信息如下: \n" + str(e))
... finally:
...     print("程序运行结束!!")
...
2
程序运行结束!!

---

2.3 捕获多个异常？

每个except捕获一个异常

一个 try语句可能有多个 except子句，以指定不同异常的处理程序，但是最多会执行一个处理程序。

当代码 A在运行中抛出了异常时，Python 解释器会逐行运行代码，如果抛出的异常是 exception1那么后面直接运行代码B，运行完 B后，就不会再判断后面两个except语句了。

而如果不是exception1，而是 exception2，那会运行代码C，而不会再运行第三个except语句了。

try:
    代码A
except [exception1] as e:
    代码B
except [exception2] as e:
    代码C
except [exception3] as e:
    代码D

举个例子吧，下面这段代码，由于 1/0会抛出 ZeroDivisionError错误，所以前面两个异常匹配都不成功，而在最后一个except成功匹配上，最终打印出 除数不能为 0

try:
    1/0
except IOError:
    print("IO读写出错")
except FloatingPointError:
    # 浮点计算错误
    print("计算错误")
except ZeroDivisionError:
    # 除数不能为 0
    print("计算错误")
# output: 计算错误

---

一个except捕获多个异常

上面的例子可以看出来，第二个异常和第三个异常是属于同一类，就是 计算错误，异常处理的代码是一样的，那有没有办法将它们合并在一起呢，简化一下代码呢？

答案是，可以的。

在except后面其实是可以接多个异常的，多个异常之间使用括号包裹。只要匹配上一个就算捕获到，就会进入相应的代码分支。

try:
    1/0
except IOError:
    print("IO读写出错")
except (ZeroDivisionError, FloatingPointError):
    print("计算出错")
# output: 计算错误

---

3. 如何自定义异常

大多数情况下，内置的错误和异常已经够用了，但是有时候你还是需要自定义一些异常。

自定义异常，需要你对 类 与 继承 有一些了解，对于类的知识，我放在了第七章，因此你可以先前往学习下第七章的的下面两节内容：

7.1 类的理解与使用
7.5 类的继承（Inheritance）
等学习完后再回过头来学习本节内容。

自定义异常应该继承 Exception类，直接继承或者间接继承都可以，自定义的异常或错误类，下面使用 InputError，表示接受用户输入时发生问题。

class InputError(Exception):
    def __init__(self, msg):
        self.message = msg

    def __str__(self):
        return self.message

异常的名字都以Error结尾，我们在为自定义异常命名的时候也需要遵守这一规范，就跟标准的异常命名一样。

定义完后，再看如下代码，我在 try里调用 get_input函数，如果发现用户没有输入内容，就使用 raise关键字来抛出 InputError。

def get_input():
    name = input("请输入你的姓名：")
    if name == "":
        raise InputError("未输入内容")

try:
    get_input()
except InputError as e:
    print(e)

---

4. 【进阶】如何关闭异常自动关联上下文

当你在处理异常时，由于处理不当或者其他问题，再次抛出另一个异常时，往外抛出的异常也会携带原始的异常信息。

就像这样子。

try:
    print(1 / 0)
except Exception as exc:
    raise RuntimeError("Something bad happened")

从输出可以看到两个异常信息

Traceback (most recent call last):
  File "demo.py", line 2, in <module>
    print(1 / 0)
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "demo.py", line 4, in <module>
    raise RuntimeError("Something bad happened")
RuntimeError: Something bad happened

如果在异常处理程序或finally块中引发异常，默认情况下，异常机制会隐式工作会将先前的异常附加为新异常的__context__属性。这就是 Python 默认开启的自动关联异常上下文。

如果你想自己控制这个上下文，可以加个 from关键字（from 语法会有个限制，就是第二个表达式必须是另一个异常类或实例。），来表明你的新异常是直接由哪个异常引起的。

try:
    print(1/0)
except Exception as exc:
    raise RuntimeError("Something bad happened") from exc

输出如下

Traceback (most recent call last):
  File "demo.py", line 2, in <module>
    print(1 / 0)
ZeroDivisionError: division by zero

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "demo.py", line 4, in <module>
    raise RuntimeError("Something bad happened") from exc
RuntimeError: Something bad happened

当然，你也可以通过with_traceback()方法为异常设置上下文__context__属性，这也能在traceback更好的显示异常信息。

try:
    print(1 / 0)
except Exception as exc:
    raise RuntimeError("bad thing").with_traceback(exc)

最后，如果我想彻底关闭这个自动关联异常上下文的机制？有什么办法呢？

可以使用 raise...from None，从下面的例子上看，已经没有了原始异常

$ cat demo.py
try:
    print(1 / 0)
except Exception as exc:
    raise RuntimeError("Something bad happened") from None
$
$ python demo.py
Traceback (most recent call last):
  File "demo.py", line 4, in <module>
    raise RuntimeError("Something bad happened") from None
RuntimeError: Something bad happened
(PythonCodingTime)

---

5. 【进阶】异常处理的三个好习惯

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

异常处理工作由“捕获”和“抛出”两部分组成。“捕获”指的是使用try ... except包裹特定语句，妥当的完成错误流程处理。而恰当的使用raise主动“抛出”异常，更是优雅代码里必不可少的组成部分。

在这篇文章里，我会分享与异常处理相关的 3 个好习惯。继续阅读前，我希望你已经了解了下面这些知识点：

异常的基本语法与用法（建议阅读官方文档“Errors and Exceptions”）
为什么要使用异常代替错误返回（建议阅读*`《让函数返回结果的技巧》 https://www.zlovezl.cn/articles/function-returning-tips/
为什么在写 Python 时鼓励使用异常 （建议阅读“Write Cleaner Python: Use Exceptions”）

---

5.1 只做最精确的异常捕获

假如你不够了解异常机制，就难免会对它有一种天然恐惧感。你可能会觉得：异常是一种不好的东西，好的程序就应该捕获所有的异常，让一切都平平稳稳的运行。而抱着这种想法写出的代码，里面通常会出现大段含糊的异常捕获逻辑。

让我们用一段可执行脚本作为样例：

# -*- coding: utf-8 -*-
import requests
import re


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

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

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


def main():
    save_website_title('https://www.qq.com', 'qq_title.txt')


if __name__ == '__main__':
    main()

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

那么，这段看上去简洁易懂的代码，里面藏着什么问题呢？

如果你旁边刚好有一台安装了 Python 的电脑，那么你可以试着跑一遍上面的脚本。你会发现，上面的代码是不能成功执行的。而且你还会发现，无论你如何修改网址和目标文件的值，程序仍然会报错 “save failed: unable to…”。为什么呢？

问题就藏在这个硕大无比的try ... except语句块里。假如你把眼睛贴近屏幕，非常仔细的检查这段代码。你会发现在编写函数时，我犯了一个小错误，我把获取正则匹配串的方法错打成了 obj.grop(1)，少了一个 ‘u’（obj.group(1))。

但正是因为那个过于庞大、含糊的异常捕获，这个由打错方法名导致的原本该被抛出的 AttibuteError却被吞噬了。从而给我们的 debug过程增加了不必要的麻烦。

异常捕获的目的，不是去捕获尽可能多的异常。假如我们从一开始就坚持：只做最精准的异常捕获。那么这样的问题就根本不会发生，精准捕获包括：

1. 永远只捕获那些可能会抛出异常的语句块
2. 尽量只捕获精确的异常类型，而不是模糊的Exception

依照这个原则，我们的样例应该被改成这样：

from requests.exceptions import RequestException


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

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

    try:
        with open(filename, 'w') as fp:
            fp.write(title)
    except IOError as e:
        print(f'save failed: unable to write to file {filename}: {e}')
        return False
    else:
        return True

---

5.2 别让异常破坏抽象一致性

大约四五年前，当时的我正在开发某移动应用的后端 API项目。如果你也有过开发后端 API的经验，那么你一定知道，这样的系统都需要制定一套“API 错误码规范”，来为客户端处理调用错误时提供方便。

一个错误码返回大概长这个样子：

// HTTP Status Code: 400
// Content-Type: application/json
{
    "code": "UNABLE_TO_UPVOTE_YOUR_OWN_REPLY",
    "detail": "你不能推荐自己的回复"
}

在制定好错误码规范后，接下来的任务就是如何实现它。当时的项目使用了Django框架，而 Django的错误页面正是使用了异常机制实现的。打个比方，如果你想让一个请求返回404状态码，那么只要在该请求处理过程中执行 raise Http404即可。

所以，我们很自然的从Django获得了灵感。首先，我们在项目内定义了错误码异常类：APIErrorCode。然后依据“错误码规范”，写了很多继承该类的错误码。当需要返回错误信息给用户时，只需要做一次 raise 就能搞定。

raise error_codes.UNABLE_TO_UPVOTE
raise error_codes.USER_HAS_BEEN_BANNED
... ...

毫无意外，所有人都很喜欢用这种方式来返回错误码。因为它用起来非常方便，无论调用栈多深，只要你想给用户返回错误码，调用raise error_codes.ANY_THING就好。

随着时间推移，项目也变得越来越庞大，抛出 APIErrorCode的地方也越来越多。有一天，我正准备复用一个底层图片处理函数时，突然碰到了一个问题。

我看到了一段让我非常纠结的代码：

# 在某个处理图像的模块内部
# <PROJECT_ROOT>/util/image/processor.py
def process_image(...):
    try:
        image = Image.open(fp)
    except Exception:
        # 说明（非项目原注释）：该异常将会被 Django 的中间件捕获，往前端返回
        # "上传的图片格式有误" 信息
        raise error_codes.INVALID_IMAGE_UPLOADED
    ... ...

process_image函数会尝试解析一个文件对象，如果该对象不能被作为图片正常打开，就抛出 error_codes.INVALID_IMAGE_UPLOADED （APIErrorCode 子类）异常，从而给调用方返回错误代码 JSON。

让我给你从头理理这段代码。最初编写process_image时，我虽然把它放在了 util.image模块里，但当时调这个函数的地方就只有 “处理用户上传图片的 POST 请求”而已。为了偷懒，我让函数直接抛出APIErrorCode异常来完成了错误处理工作。

再来说当时的问题。那时我需要写一个在后台运行的批处理图片脚本，而它刚好可以复用 process_image函数所实现的功能。但这时不对劲的事情出现了，如果我想复用该函数，那么：

1. 我必须去捕获一个名为INVALID_IMAGE_UPLOADED的异常
2. 哪怕我的图片根本就不是来自于用户上传
3. 我必须引入 APIErrorCode异常类作为依赖来捕获异常
4. 哪怕我的脚本和 Django API根本没有任何关系

这就是异常类抽象层级不一致导致的结果。APIErrorCode异常类的意义，在于表达一种能够直接被终端用户（人）识别并消费的“错误代码”。它在整个项目里，属于最高层的抽象之一。但是出于方便，我们却在底层模块里引入并抛出了它。这打破了image.processor模块的抽象一致性，影响了它的可复用性和可维护性。

这类情况属于“模块抛出了高于所属抽象层级的异常”。避免这类错误需要注意以下几点：

• 让模块只抛出与当前抽象层级一致的异常
• 比如 image.processer模块应该抛出自己封装的 ImageOpenError异常
• 在必要的地方进行异常包装与转换
• 比如，应该在贴近高层抽象（视图 View函数）的地方，将图像处理模块的ImageOpenError低级异常包装转换为APIErrorCode高级异常

修改后的代码：

# <PROJECT_ROOT>/util/image/processor.py
class ImageOpenError(Exception):
    pass


def process_image(...):
    try:
        image = Image.open(fp)
    except Exception as e:
        raise ImageOpenError(exc=e)
    ... ...

# <PROJECT_ROOT>/app/views.py
def foo_view_function(request):
    try:
        process_image(fp)
    except ImageOpenError:
        raise error_codes.INVALID_IMAGE_UPLOADED

除了应该避免抛出高于当前抽象级别的异常外，我们同样应该避免泄露低于当前抽象级别的异常。

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

>>> try:
...     requests.get('https://www.invalid-host-foo.com')
... except Exception as e:
...     print(type(e))
...
<class 'requests.exceptions.ConnectionError'>

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

---

5.3 异常处理不应该喧宾夺主

在前面我们提到异常捕获要精准、抽象级别要一致。但在现实世界中，如果你严格遵循这些流程，那么很有可能会碰上另外一个问题：异常处理逻辑太多，以至于扰乱了代码核心逻辑。具体表现就是，代码里充斥着大量的try、except、raise语句，让核心逻辑变得难以辨识。

让我们看一段例子：

def upload_avatar(request):
    """用户上传新头像"""
    try:
        avatar_file = request.FILES['avatar']
    except KeyError:
        raise error_codes.AVATAR_FILE_NOT_PROVIDED

    try:
       resized_avatar_file = resize_avatar(avatar_file)
    except FileTooLargeError as e:
        raise error_codes.AVATAR_FILE_TOO_LARGE
    except ResizeAvatarError as e:
        raise error_codes.AVATAR_FILE_INVALID

    try:
        request.user.avatar = resized_avatar_file
        request.user.save()
    except Exception:
        raise error_codes.INTERNAL_SERVER_ERROR
    return HttpResponse({})

这是一个处理用户上传头像的视图函数。这个函数内做了三件事情，并且针对每件事都做了异常捕获。如果做某件事时发生了异常，就返回对用户友好的错误到前端。

这样的处理流程纵然合理，但是显然代码里的异常处理逻辑有点“喧宾夺主”了。一眼看过去全是代码缩进，很难提炼出代码的核心逻辑。

早在 2.5 版本时，Python 语言就已经提供了对付这类场景的工具：“上下文管理器（context manager）”。上下文管理器是一种配合 with语句使用的特殊 Python 对象，通过它，可以让异常处理工作变得更方便。

那么，如何利用上下文管理器来改善我们的异常处理流程呢？让我们直接看代码吧。

class raise_api_error:
    """captures specified exception and raise ApiErrorCode instead

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

    def __enter__(self):
        # 该方法将在进入上下文时调用
        return self

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

        if exc_type == self.captures:
            raise self.code from exc_val
        return False

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

使用该上下文管理器后，整个函数可以变得更清晰简洁：

def upload_avatar(request):
    """用户上传新头像"""
    with raise_api_error(KeyError, 'AVATAR_FILE_NOT_PROVIDED'):
        avatar_file = request.FILES['avatar']

    with raise_api_error(ResizeAvatarError, 'AVATAR_FILE_INVALID'),\
            raise_api_error(FileTooLargeError, 'AVATAR_FILE_TOO_LARGE'):
        resized_avatar_file = resize_avatar(avatar_file)

    with raise_api_error(Exception, 'INTERNAL_SERVER_ERROR'):
        request.user.avatar = resized_avatar_file
        request.user.save()
    return HttpResponse({})

Hint：建议阅读 PEP 343 – The “with” Statement | Python.org，了解与上下文管理器有关的更多知识。

模块 contextlib也提供了非常多与编写上下文管理器相关的工具函数与样例。

总结一下

在这篇文章中，我分享了与异常处理相关的三个建议。最后再总结一下要点：

1. 只捕获可能会抛出异常的语句，避免含糊的捕获逻辑
2. 保持模块异常类的抽象一致性，必要时对底层异常类进行包装
3. 使用“上下文管理器”可以简化重复的异常处理逻辑

---