thoughyou revise it (as programmers are prone to do!along the wayyou identify new thing that can go wrong--underflowperhaps--and add that as new exceptionmathlib py class divzero(exception)pass class oflow(exception)pass class uflow(exception)pass unfortunatelywhen you re-release your codeyou create maintenance problem for your users if they've listed your exceptions explicitlythey now have to go back and change every place they call your library to include the newly added exception nameclient py trymathlib funcexcept (mathlib divzeromathlib oflowmathlib uflow)handle and recover this may not be the end of the world if your library is used only in-houseyou can make the changes yourself you might also ship python script that tries to fix such code automatically (it would probably be only few dozen linesand it would guess right at least some of the timeif many people have to change all their try statements each time you alter your exception setthoughthis is not exactly the most polite of upgrade policies your users might try to avoid this pitfall by coding empty except clauses to catch all possible exceptionsclient py trymathlib funcexcepthandle and recover catch everything here (or catch exception superbut this workaround might catch more than they bargained for--things like running out of memorykeyboard interrupts (ctrl- )system exitsand even typos in their own try block' code will all trigger exceptionsand such things should passnot be caught and erroneously classified as library errors catching the exception super class improves on thisbut still intercepts--and thus may mask--program errors and reallyin this scenario users want to catch and recover from only the specific exceptions the library is defined and documented to raise if any other exception occurs during library callit' likely genuine bug in the library (and probably time to contact the vendor!as rule of thumbit' usually better to be specific than general in exception handlers--an idea we'll revisit as "gotchain the next why exception hierarchies