# client.py import mathlib ... try: mathlib.func(...) except mathlib.NumErr: ...report and recover... When you go back and hack your code again, you can add new exceptions as new subclasses of the common superclass: # mathlib.py ... class Uflow(NumErr): pass The end result is that user code that catches your library's exceptions will keep working, unchanged. In fact, you are free to add, delete, and change exceptions arbitrarily in the future--as long as clients name the superclass, they are insulated from changes in your exceptions set. In other words, class exceptions provide a better answer to maintenance issues than strings do. Class-based exception hierarchies also support state retention and inheritance in ways that make them ideal in larger programs. To understand these roles, though, we first need to see how user-defined exception classes relate to the built-in exceptions from which they inherit.