摘要

自 Python 2.4 版本起，内置命名空间中有 38 个异常（包括警告），层级结构相当浅。这些类经过多年发展，没有机会从经验中学习。本 PEP 建议在 Python 3.0 中重组层级结构，此时向后兼容性不再是主要问题。

除了此次重组之外，还建议要求所有传递给 raise 语句的对象都必须继承自一个特定的超类。这是为了保证异常的基本接口，并进一步增强异常的自然层级结构。

最后，裸 except 子句将被修改为在语义上等同于 except Exception。大多数人目前都将裸 except 子句用于此目的，并且随着异常层级结构的重组，它成为一个可行的默认设置。

更改理由

异常是 Python 的关键部分。虽然异常传统上用于表示程序中的错误，但它们也已用于流控制，例如迭代器。

虽然它们很重要，但却缺乏结构。这源于任何对象都可以作为异常被抛出。因此，您无法保证将抛出何种类型的对象，从而破坏了任何可能被抛出对象遵守的层级结构。

但异常确实有一个层级结构，显示了异常的严重性。该层级结构还将相关异常分组在一起，以简化在 except 子句中捕获它们。为了让人们能够依赖此层级结构，正在提议一个所有抛出对象都必须继承的共同超类。它还允许对抛出对象的接口进行保证（参见 PEP 344）。所有这些的讨论之前已在 python-dev 上进行过 [1]。

目前的裸 except 子句会捕获*所有*异常。虽然这很方便，但对于常见情况来说过于宽泛。由于有了必需的超类，捕获所有异常就像捕获一个特定异常一样简单。这使得裸 except 子句可以用于更有用的目的。再次强调，这已在 python-dev 上讨论过 [2]。

最后，对异常层级结构的微小更改将使其在结构上更加合理。通过对异常进行细微的重新排列，那些通常不应被捕获的异常可以被允许传播到执行堆栈的顶部，从而按预期终止解释器。

重组理念

对于层级结构的重组，遵循了从本 PEP 早期草案的讨论中发展出来的一般理念 [4]、[5]、[6]、[7]、[8]、[9]。首先也是最重要的是不破坏任何正常工作的东西。这意味着重命名异常是不可取的，除非名称被认为严重不佳。这也意味着除非异常被认为是真正放错了位置，否则不会移除异常。只有在可能需要捕获某类异常的超类的情况下，才会引入新异常。最后，现有异常的继承树只会在它们最初就被认为真正放错了位置的情况下才会更改。

对于所有新异常，必须选择正确的后缀。对于表示错误的异常，使用“Error”。如果异常是警告，则使用“Warning”。当其他后缀都不合适且没有更合适的特定后缀时，使用“Exception”。

之后，就归结为选择哪些异常应该和不应该继承自 Exception。这是为了使裸 except 子句更有用。

最后，整个现有层级结构必须继承自旨在作为所有异常必须继承的所需超类的新异常。

新层级结构

+-- BaseException (new; broader inheritance for subclasses)
    +-- Exception
        +-- GeneratorExit (defined in PEP 342)
        +-- StandardError
            +-- ArithmeticError
                +-- DivideByZeroError
                +-- FloatingPointError
                +-- OverflowError
            +-- AssertionError
            +-- AttributeError
            +-- EnvironmentError
                +-- IOError
                +-- EOFError
                +-- OSError
            +-- ImportError
            +-- LookupError
                +-- IndexError
                +-- KeyError
            +-- MemoryError
            +-- NameError
                +-- UnboundLocalError
            +-- NotImplementedError (stricter inheritance)
            +-- SyntaxError
                +-- IndentationError
                    +-- TabError
            +-- TypeError
            +-- RuntimeError
            +-- UnicodeError
                +-- UnicodeDecodeError
                +-- UnicodeEncodeError
                +-- UnicodeTranslateError
            +-- ValueError
            +-- ReferenceError
        +-- StopIteration
        +-- SystemError
        +-- Warning
            +-- DeprecationWarning
            +-- FutureWarning
            +-- PendingDeprecationWarning
            +-- RuntimeWarning
            +-- SyntaxWarning
            +-- UserWarning
        + -- WindowsError
    +-- KeyboardInterrupt (stricter inheritance)
    +-- SystemExit (stricter inheritance)

与 Python 2.4 的差异

在讨论继承更改时，需要更彻底地解释术语。继承更改会导致更广泛或更严格的继承。“更广泛”是指一个类的继承树为 cls, A，然后变为 cls, B, A。“更严格”则相反。

raise 所需的超类

通过要求传递给 raise 语句的所有对象都继承自一个特定的超类，可以保证所有异常都具有某些属性。如果 PEP 344 被接受，其中概述的属性将保证存在于所有抛出的异常上。这应该通过使从异常中查询信息变得更容易来帮助调试。

提议的层级结构以 BaseException 作为必需的基类。

裸 except 子句捕获 Exception

在大多数现有的 Python 2.4 代码中，裸 except 子句捕获的异常范围太广。通常只希望捕获表示错误的异常。这意味着在常见情况下不应捕获用于表示解释器应退出的异常。

随着 KeyboardInterrupt 和 SystemExit 被移至继承自 BaseException 而非 Exception，将裸 except 子句更改为等同于 except Exception 成为一个更合理的默认值。这一更改也将很少破坏现有代码，因为这些语义是大多数人对裸 except 子句所期望的。

已经有人主张完全移除裸 except 子句。理由是它们违反了《Python 之禅》中列出的“只有一种方法可以做到”（OOWTDI）和“显式优于隐式”（EIBTI）原则。但“实用胜于纯粹”（PBP），同样在《Python 之禅》中，在这种情况下胜过这两个原则。BDFL 已经声明裸 except 子句将以这种方式工作 [14]。

过渡计划

由于为本 PEP 中计划的所有功能添加所需的高度复杂性和混乱，过渡计划非常简单。在 Python 2.5 中添加 BaseException。在 Python 3.0 中，所有剩余的功能（必需的超类、继承更改、裸 except 子句与 except Exception 相同）将生效。为了使所有这些在 Python 2.5 中以向后兼容的方式工作，将需要对异常机制进行非常深入的修改，这可能会容易出错，并导致性能下降，而收益甚微。

为了帮助过渡，文档将进行更改以反映以下几项编程指南：

• 当想要捕获*所有*异常时，捕获 BaseException
• 要捕获所有不表示解释器终止的异常，请显式捕获 Exception
• 显式捕获 KeyboardInterrupt 和 SystemExit；不要依赖 Exception 的继承来导致捕获
• 始终显式捕获 NotImplementedError，而不是依赖 RuntimeError 的继承

“exceptions”模块 [3]、教程 [15] 和 PEP 290 的文档都将需要更新。

被拒绝的想法

致谢

感谢 Robert Brewer、Josiah Carlson、Alyssa Coghlan、Timothy Delaney、Jack Diedrich、Fred L. Drake, Jr.、Philip J. Eby、Greg Ewing、James Y. Knight、MA Lemburg、Guido van Rossum、Stephen J. Turnbull、Raymond Hettinger，以及所有我遗漏的参与讨论的人。

参考资料

版权

本文档已置于公共领域。