doesn' document it exhaustively you can read further about this structure in reference texts such as python pocket reference or the python library manual in factthe exceptions class tree differs slightly between python and in ways we'll omit herebecause they are not relevant to examples you can also see the built-in exceptions class tree in the help text of the exceptions module in python only (see and for help on help)import exceptions help(exceptionslots of text omitted this module is removed in xwhere you'll find up-to-date help in the other resources mentioned built-in exception categories the built-in class tree allows you to choose how specific or general your handlers will be for examplebecause the built-in exception arithmeticerror is superclass for more specific exceptions such as overflowerror and zerodivisionerrorby listing arithmeticerror in tryyou will catch any kind of numeric error raised by listing zerodivisionerroryou will intercept just that specific type of errorand no others similarlybecause exception is the superclass of all application-level exceptions in python xyou can generally use it as catchall--the effect is much like an empty exceptbut it allows system exit exceptions to pass and propagate as they usually shouldtryaction(except exceptionhandle all application exceptions elsehandle no-exception case exits not caught here this doesn' quite work universally in python xhoweverbecause standalone userdefined exceptions coded as classic classes are not required to be subclasses of the exception root class this technique is more reliable in python xsince it requires all classes to derive from built-in exceptions even in python xthoughthis scheme suffers most of the same potential pitfalls as the empty exceptas described in the prior -it might intercept exceptions intended for elsewhereand it might mask genuine programming errors since this is such common issuewe'll revisit it as "gotchain the next exception objects