预计阅读本页时间：-
Catching Too Little: Use Class-Based Categories
On the other hand, neither should handlers be too specific. When you list specific exceptions in a try, you catch only what you actually list. This isn’t necessarily a bad thing, but if a system evolves to raise other exceptions in the future, you may need to go back and add them to exception lists elsewhere in your code.
We saw this phenomenon at work in the prior chapter. For instance, the following handler is written to treat MyExcept1 and MyExcept2 as normal cases and everything else as an error. Therefore, if you add a MyExcept3 in the future, it will be processed as an error unless you update the exception list:
广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元
try:
...
except (MyExcept1, MyExcept2): # Breaks if you add a MyExcept3
... # Non-errors
else:
... # Assumed to be an error
Luckily, careful use of the class-based exceptions we discussed in Chapter 33 can make this trap go away completely. As we saw, if you catch a general superclass, you can add and raise more specific subclasses in the future without having to extend except clause lists manually—the superclass becomes an extendible exceptions category:
try:
...
except SuccessCategoryName: # OK if I add a myerror3 subclass
... # Non-errors
else:
... # Assumed to be an error
In other words, a little design goes a long way. The moral of the story is to be careful to be neither too general nor too specific in exception handlers, and to pick the granularity of your try statement wrappings wisely. Especially in larger systems, exception policies should be a part of the overall design.
[79] A related call, os._exit, also ends a program, but via an immediate termination—it skips cleanup actions and cannot be intercepted with try/except or try/finally blocks. It is usually only used in spawned child processes, a topic beyond this book’s scope. See the library manual or follow-up texts for details.
