Is Python a

Now, when people use your library, they will typically wrap calls to your functionsor classes in try statements that catch your two exceptions (if they do not catch yourexceptions, exceptions from the library kill their code):# client.pyimport mathlib...try:mathlib.func(...)except (mathlib.divzero, mathlib.oflow):...report and recover...This works fine, and lots of people start using your library. Six months down theroad, though, you revise it. Along the way, you identify a new thing that can gowrong—underflow—and add that as a new string exception:# mathlib.pydivzero = 'Division by zero error in library'oflow = 'Numeric overflow error in library'uflow = 'Numeric underflow error in library'Unfortunately, when you rerelease your code, you create a maintenance problem foryour users. If they’ve listed your exceptions explicitly, they now have to go back andchange every place they call your library to include the newly added exception name:# client.pytry:mathlib.func(...)except (mathlib.divzero, mathlib.oflow, mathlib.uflow):...report and recover...This may not be the end of the world. If your library is used only in-house, you canmake the changes yourself. You might also ship a Python script that tries to fix suchcode automatically (it would probably be only a few dozen lines, and it would guessright at least some of the time). If many people have to change their code each timeyou alter your exception set, though, this is not exactly the most polite of upgradepolicies.Your users might try to avoid this pitfall by coding empty except clauses to catch allpossible exceptions:# client.pytry:mathlib.func(...)except:...report and recover...# Catch everything hereClass-Based Exceptions | 607