- Modern Python Cookbook
- Steven F. Lott
- 443字
- 2021-06-11 18:49:13
Avoiding a potential problem with an except: clause
There are some common mistakes in exception handling. These can cause programs to become unresponsive.
One of the mistakes we can make is to use the except: clause with no named exceptions to match. There are a few other mistakes that we can make if we're not cautious about the exceptions we try to handle.
This recipe will show some common exception handling errors that we can avoid.
Getting ready
When code can raise a variety of exceptions, it's sometimes tempting to try and match as many as possible. Matching too many exceptions can interfere with stopping a misbehaving Python program. We'll extend the idea of what not to do in this recipe.
How to do it...
We need to avoid using the bare except: clause. Instead, use except Exception: to match the most general kind of exception that an application can reasonably handle.
Handling too many exceptions can interfere with our ability to stop a misbehaving Python program. When we hit Ctrl + C, or send a SIGINT signal via the OS's kill -2 command, we generally want the program to stop. We rarely want the program to write a message and keep running. If we use a bare except: clause, we can accidentally silence important exceptions.
There are a few other classes of exceptions that we should be wary of attempting to handle:
- SystemError
- RuntimeError
- MemoryError
Generally, these exceptions mean things are going badly somewhere in Python's internals. Rather than silence these exceptions, or attempt some recovery, we should allow the program to fail, find the root cause, and fix it.
How it works...
There are two techniques we should avoid:
- Don't capture the BaseException class.
- Don't use except: with no exception class. This matches all exceptions, including exceptions we should avoid trying to handle.
Using either of the above techniques can cause a program to become unresponsive at exactly the time we need to stop it. Further, if we capture any of these exceptions, we can interfere with the way these internal exceptions are handled:
- SystemExit
- KeyboardInterrupt
- GeneratorExit
If we silence, wrap, or rewrite any of these, we may have created a problem where none existed. We may have exacerbated a simple problem into a larger and more mysterious problem.
It's a noble aspiration to write a program that never crashes. Interfering with some of Python's internal exceptions, however, doesn't create a more reliable program. Instead, it creates a program where a clear failure is masked and made into an obscure mystery.
See also
- In the Leveraging the exception matching rules recipe, we look at some considerations when designing exception-handling statements.
- pcDuino開發實戰
- 蘋果電腦玩全攻略 OS X 10.8 Mountain Lion
- Ganglia系統監控
- Windows Phone 7.5 Data Cookbook
- Python基礎教程(第3版)
- 竹林蹊徑:深入淺出windows驅動開發
- Joomla! 3 Template Essentials
- 分布式高可用架構之道
- OpenVZ Essentials
- Windows網絡編程(第2版)
- openEuler操作系統核心技術與行業應用實踐
- Mastering Eclipse Plug-in Development
- Xamarin Mobile Application Development for Android
- Mastering AWS CloudFormation
- Linux網絡操作系統項目教程(RHEL 6.4/CentOS 6.4)(第2版)