and exception catchers are handybut potentially error-prone in the last examplefor instanceyou would be better off saying except keyerrorto make your intentions explicit and avoid intercepting unrelated events in simpler scriptsthe potential for problems might not be significant enough to outweigh the convenience of catchallbut in generalgeneral handlers are generally trouble catching too littleuse class-based categories on the other handneither should handlers be too specific when you list specific exceptions in tryyou catch only what you actually list this isn' necessarily bad thingbut if system evolves to raise other exceptions in the futureyou may need to go back and add them to exception lists elsewhere in your code we saw this phenomenon at work in the prior for instancethe following handler is written to treat myexcept and myexcept as normal cases and everything else as an error if you add myexcept in the futurethoughit will be processed as an error unless you update the exception listtryexcept (myexcept myexcept )elsebreaks if you add myexcept later nonerrors assumed to be an error luckilycareful use of the class-based exceptions we discussed in can make this code maintenance trap go away completely as we sawif you catch general superclassyou can add and raise more specific subclasses in the future without having to extend except clause lists manually--the superclass becomes an extendible exceptions categorytryexcept successcategorynameelseok if you add myexcept subclass later nonerrors assumed to be an error in other wordsa little design goes long way the moral of the story is to be careful to be neither too general nor too specific in exception handlersand to pick the granularity of your try statement wrappings wisely especially in larger systemsexception policies should be part of the overall design core language summary congratulationsthis concludes your look at the fundamentals of the python programming language if you've gotten this faryou've become fully operational python core language summary