than defining your library' exceptions as set of autonomous classesarrange them into class tree with common superclass to encompass the entire categorymathlib py class numerr(exception)pass class divzero(numerr)pass class oflow(numerr)pass def func()raise divzero(and so on this wayusers of your library simply need to list the common superclass ( categoryto catch all of your library' exceptionsboth now and in the futureclient py import mathlib trymathlib funcexcept mathlib numerrreport and recover when you go back and hack (updateyour code againyou can add new exceptions as new subclasses of the common superclassmathlib py class uflow(numerr)pass the end result is that user code that catches your library' exceptions will keep workingunchanged in factyou are free to adddeleteand change exceptions arbitrarily in the future--as long as clients name the superclassand that superclass remains intactthey are insulated from changes in your exceptions set in other wordsclass exceptions provide better answer to maintenance issues than strings could class-based exception hierarchies also support state retention and inheritance in ways that make them ideal in larger programs to understand these rolesthoughwe first as clever student of mine suggestedthe library module could also provide tuple object that contains all the exceptions the library can possibly raise--the client could then import the tuple and name it in an except clause to catch all the library' exceptions (recall that including tuple in an except means catch any of its exceptionswhen new exceptions are added laterthe library can just expand the exported tuple this would workbut you' still need to keep the tuple up-to-date with raised exceptions inside the library module alsoclass hierarchies offer more benefits than just categories--they also support inherited state and methods and customization model that individual exceptions do not exception objects