Python 异常处理完整指南（下）

组织结构

你可以随时随地的定义异常，可以是任意的类，任意的包，函数，甚至是闭包。

很多的库都有他们自己定义的异常模块：SQLAlchemy的异常定义在sqlalchemy.exc中，requests在request.exceptions中，Werkzeug在wekzeug.exceptions中，等等..

这些正常的包都能通过刚才的方法导出异常，同事也能方便的被用户所调用他们的异常模块，并且知道异常在哪里被定义，什么时候来用哪种异常处理代码可能发生的异常。

不过这些都不是强制的，越小的Python模块可能越想把异常整合在他们唯一的模块中。通常如果你的代码小到只有一个文件，就不用非得把代码和异常分成不同的文件或者模块。

当然对于库的明智的选择是，把他们分成不同的文件或者模块。如果每个子系统都有一系列的异常通常就把他们放在这个子系统中。这也是为什么我不推荐一个系统中只放一个异常模块。这样myapp.exceptions就可能没必要了。

例如，如果你的应用已经被一个定义在myapp.http的HTTP REST API所包含，并且他还是一个TCP服务器myapp.tcp的一部分，这样就他们就很可能同事定义不同的异常比如他们自己协议的错误或者消息请求生命周期的错误。如果把这些异常都写在myapp.exceptions里就会破坏代码的一致性，如果异常以诗歌本地文件，就把它们定义在这个文件的头部就好了。这将减缓维护代码的成本。

异常的包裹

包装异常就是将一个异常封装到另一个异常中:

当写一个库的时候利用其它库这是有意义的．如果一个库使用了　requests，但他并没将requests异常封装到他自己定义的异常类中，这会影响异常的传递．任何程序使用你的库可能会收到一个requests.exceptions.ConnectionError，这个问题的因为是:

requests对应用程序来说是透明的，应用程序也不需要/不想知道requests．
应用程序不得不导入requests.exceptions ，因此它将依赖 requests—即使它不直接使用它.
一旦我的mylib库从requests 迁移到httplib2, 应用程序中捕获requests异常的代码将会显得多余．

Tooz 库就是封装的很好例子，由于它使用了基于驱动的方法并且依赖许多不同的Python模块与不同的后台服务进行交互 (ZooKeeper, PostgreSQL, 等…). 因此, 它将其它模块的各个场景的异常封装到自己的一组异常类中．Python 3引入了raise from来解决这个问题，Tooz利用它来抛出自己的错误。

就像上面做的那样，将原始异常封装到用户自定义异常中也是可行的．它使得我们可以很方便的查检原始异常．

捕获异常并记录日志

当设计异常时，它应当针对人为因素与电脑因素，记住这很重要．这就是为什么它应该包含明显的消息，并尽可能多的包含信息．这将有助于调试并且编写有弹性的代码，可以依赖异常的属性来观察它的行为，就向上面看到的那样．

完全忽略异常（不做任何处理）应当被认为是不好的编程实践．你不应该写类似那样的代码：

在异常发生的程序中如果没有任何类型的信息，对查找问题来说这就是恶梦．

如果你（应该）使用 logging 库，当有程序发生异常时，你可以使用exc_info参数来记录完整的追踪，在你调试服务或不可恢复的故障时会变得非常有用：