Question

因为上一节例子中，只有三种可能的异常，其实无法说明类异常的用处。事实上，我们可以在except子句的括号内列出字符串异常名称的清单，从而可以达到相同效果。

这种方法对于已经废弃的字符串异常模式也有效。然而，就大型或多层次的异常而言，在一个except子句中使用类捕捉分类，会比列出一个分类中的每个成员更为简单。此外，可以新增子类扩展异常层次，而不会破坏现有的代码。

假设用Python编写了一个数值计算库，可供许多人使用。当编写库时，有两件事会让代码中的数值出错：除数为零以及数值溢出。在文档中指出这些是异常，可以通过库引发这两个异常，同时在代码中将异常定义为简单字符串。

现在，当人们使用库的时候，他们一般会在try语句内，把对函数或类的调用包装起来，从而捕捉两个异常（如果他们没捕捉异常，库的异常会终止代码）。

这样运作起来没有什么问题，许多人开始使用你的库。然而，发布了六个月后，你做了些修改。在这个过程中，你发现有新的情况也会出错：退位（underflow），于是，新增了一个字符串异常。

不幸的是，当你发布代码时，就给用户创造了一个维护问题。如果他们要明确地列出你的异常，现在就得回去修改每处调用你的库的地方，来引入新增的异常名。

这也许不是世界末日。如果你的库只是给自己使用，可以自己修改。你也可以发布一个Python脚本，试着自动修改这类代码（可能只有几十行，至少在一段时间内能猜测正确）。不过，如果每次修改异常集后，就有许多人得修改他们的代码，这就不是一个最合理的升级策略了。

用户可能为了避免这种麻烦，而编写了空的except子句来捕捉所有可能的异常。

但是，这种权宜之计可能捕捉到不想要捕捉的异常：像内存耗尽、键盘中断（Ctrl-C）、系统退出甚至自己的try块中的代码录入错误，都将触发异常，然而，你想让这些异常通过，而不是非得捕捉到并且误以为是库错误。

实际上，在这种情况下，用户想要捕获并从中恢复的唯一的具体异常，就是库定义并记录了要引发的异常；如果在库调用中发生了任何其他的异常，很可能是库中的一个真正的bug（并且可能是该联系厂商的时候了）。基本原则就是，在异常处理器中，通常来说具体要优于一般（下一章陷阱一节会再谈这个概念）^[1]。

那么，该怎么做呢？类异常可以完全修复这种难题。不是把你的库的异常定义成简单的一组字符串，而是安排到类树中，有个共同的超类来包含整个类型。

这样的话，你的库用户只需列出共同的超类（也就是分类），来捕捉库的所有异常，无论是现在还是以后。

当你回来修改代码时，作为共同超类的新的子类来增加的新异常。

结果就是用户代码捕捉库的异常依然保持正常工作，没有改变。事实上，你可在未来任意新增、删除以及修改异常，只要客户端使用的是超类的名称，就和异常集中的修改无关。换句话说，比起字符串，对于维护的问题来说，类异常提供了更好的答案。

再者，基于类的异常层级可支持状态保留和继承，以一种对于大程序来说理想的方式。要理解这些用法，我们首先需要看看用户定义的异常类与它们所继承自的内置异常是如何相关的。

[1]有一位聪明的学生建议，库模块也可以提供元组对象，包含库可能引发的所有异常：然后，客户端可以导入元组，在except子句中上填入该元组的名称，从而捕捉库所有的异常（回想一下，except的元组指的是捕捉任何一个异常）。当稍后增加新异常时，库只需扩充导出的元组。这样也行得通，但是，你还是得更新元组，使其跟上库模块内可能引发的异常。此外，基于类的异常提供的优点不仅止于分类而已，也支持附加的状态信息、方法调用以及继承，而这些是字符串异常无法提供的。