1. Python 3.X中用户定义的异常的两个新约束是什么？
答：在3.X中，异常必须由类定义（即，引发并捕获类实例对象）。此外，必须从内置类BaseException派生异常类；大多数程序都从其Exception子类继承，以支持正常类型异常的catchall处理程序。

2.如何将基于类（class-based）的异常引发与处理程序匹配？
答：基于类的异常与超类关系匹配：在异常处理程序中命名超类将捕获该类的实例，以及类树中较低的任何子类的实例。正因为如此，您可以认为超类是一般的异常类别，子类是这些类别中更具体的异常类型。

3.说出两种可以将上下文信息附加到异常对象的方法。
答：通过在引发的实例对象中填写得到实例属性（通常在自定义类构造函数中），可以将上下文信息附加到基于类的异常。对于更简单的需求，内置异常超类提供了一个构造函数，该构造函数自动将其参数存储在实例上（作为属性args中的元组）。在异常处理程序中，列出要赋值给引发实例的变量，然后通过此名称访问附加状态信息并调用类中定义的任何方法。

4.说出两种可以为异常对象指定错误消息文本的方法。
答：可以使用自定义__str__运算符重载方法指定基于类的异常中的错误消息文本。对于更简单的需求，内置异常超类自动显示传递给类构造函数的任何内容。 print和str等操作在显式打印或作为错误消息的一部分打印时，会自动获取异常对象的显示字符串。

5.为什么今天不再使用基于字符串的异常？
答：因为Guido这么说 - 他们已经从Python 2.6和3.0中删除了。可以说有充分的理由：基于字符串的异常不支持基于类的异常的类别（categories），状态信息（state information）或行为继承（behavior inheritance）。实际上，当程序规模较小时，这使得基于字符串的异常更容易使用，但随着程序变得越来越大，使用起来越复杂。要求异常成为类的缺点会破坏现有代码，并创建向前的知识依赖 - 初学者必须首先学习类和OOP，然后才能编写新异常，或者甚至真正理解异常。事实上，这就是为什么这个相对简单的主题在很大程度上推迟到本书的这一点。无论好坏，这种依赖在今天的Python中并不罕见（有关此类内容的更多信息，请参阅前言和结论）。

注：转载《Learning Python 5th Edition》[奥莱理]

1. What are the two new constraints on user-defined exceptions in Python 3.X?
2. How are raised class-based exceptions matched to handlers?
3. Name two ways that you can attach context information to exception objects.
4. Name two ways that you can specify the error message text for exception objects.
5. Why should you not use string-based exceptions anymore today?

1. In 3.X, exceptions must be defined by classes (that is, a class instance object is raised and caught). In addition, exception classes must be derived from the built-in class BaseException; most programs inherit from its Exception subclass, to support catchall handlers for normal kinds of exceptions.
2. Class-based exceptions match by superclass relationships: naming a superclass in an exception handler will catch instances of that class, as well as instances of any of its subclasses lower in the class tree. Because of this, you can think of superclasses as general exception categories and subclasses as more specific types of exceptions within those categories.

3. You can attach context information to class-based exceptions by filling out instance attributes in the instance object raised, usually in a custom class constructor. For simpler needs, built-in exception superclasses provide a constructor that stores its arguments on the instance automatically (as a tuple in the attribute args). In exception handlers, you list a variable to be assigned to the raised instance, then go through this name to access attached state information and call any methods defined in the class.

4. The error message text in class-based exceptions can be specified with a custom __str__ operator overloading method. For simpler needs, built-in exception superclasses automatically display anything you pass to the class constructor. Operations like print and str automatically fetch the display string of an exception object when it is printed either explicitly or as part of an error message.

5. Because Guido said so—they have been removed as of both Python 2.6 and 3.0. There are arguably good reasons for this: string-based exceptions did not support categories, state information, or behavior inheritance in the way class-based exceptions do. In practice, this made string-based exceptions easier to use at first when programs were small, but more complex to use as programs grew larger. The downsides of requiring exceptions to be classes are to break existing code, and create a forward knowledge dependency—beginners must first learn classes and OOP before they can code new exceptions, or even truly understand exceptions at all. In fact, this is why this relatively straightforward topic was largely postponed until this point in the book. For better or worse, such dependencies are not uncommon in Python today (see the preface and conclusion for more on such things).