• Choose a category
• All
• Classic-Fiction

By Root 1741 0

way to define exceptions. As described earlier, however, classes have some added advantages that merit a quick look. Most prominently, they allow us to identify exception categories that are more flexible to use and maintain than simple strings. Moreover, classes naturally allow for attached exception details and support inheritance. Because they are the better approach, they are now required.

Coding details aside, the chief difference between string and class exceptions has to do with the way that exceptions raised are matched against except clauses in try statements:

String exceptions were matched by simple object identity: the raised exception was matched to except clauses by Python’s is test.

Class exceptions are matched by superclass relationships: the raised exception matches an except clause if that except clause names the exception’s class or any superclass of it.

That is, when a try statement’s except clause lists a superclass, it catches instances of that superclass, as well as instances of all its subclasses lower in the class tree. The net effect is that class exceptions support the construction of exception hierarchies: superclasses become category names, and subclasses become specific kinds of exceptions within a category. By naming a general exception superclass, an except clause can catch an entire category of exceptions—any more specific subclass will match.

String exceptions had no such concept: because they were matched by simple object identity, there was no direct way to organize exceptions into more flexible categories or groups. The net result was that exception handlers were coupled with exception sets in a way that made changes difficult.

In addition to this category idea, class-based exceptions better support exception state information (attached to instances) and allow exceptions to participate in inheritance hierarchies (to obtain common behaviors). Because they offer all the benefits of classes and OOP in general, they provide a more powerful alternative to the now defunct string-based exceptions model in exchange for a small amount of additional code.

Coding Exceptions Classes

Let’s look at an example to see how class exceptions translate to code. In the following file, classexc.py, we define a superclass called General and two subclasses called Specific1 and Specific2. This example illustrates the notion of exception categories—General is a category name, and its two subclasses are specific types of exceptions within the category. Handlers that catch General will also catch any subclasses of it, including Specific1 and Specific2:

class General(Exception): pass

class Specific1(General): pass

class Specific2(General): pass

def raiser0():

X = General() # Raise superclass instance

raise X

def raiser1():

X = Specific1() # Raise subclass instance

raise X

def raiser2():

X = Specific2() # Raise different subclass instance

raise X

for func in (raiser0, raiser1, raiser2):

try:

func()

except General: # Match General or any subclass of it

import sys

print('caught:', sys.exc_info()[0])

C:\python30> python classexc.py

caught:

caught:

caught:

This code is mostly straightforward, but here are a few implementation notes:

Exception superclass

Classes used to build exception category trees have very few requirements—in fact, in this example they are mostly empty, with bodies that do nothing but pass. Notice, though, how the top-level class here inherits from the built-in Exception class. This is required in Python 3.0; Python 2.6 allows standalone classic classes to serve as exceptions too, but it requires new-style classes to be derived from built-in exception classes just like in 3.0. Although we don’t employ it here, because Exception provides some useful behavior we’ll meet later, it’s a good idea to inherit from it in either Python.

Raising instances

In this code, we call classes to make instances for the raise statements. In the class exception model, we always