Mention bare except: clauses in PEP 8; see the python-dev archive around Dec. 22 2007 for a short discussion
This commit is contained in:
parent
594770c5ec
commit
a2a12a86ea
26
pep-0008.txt
26
pep-0008.txt
|
@ -663,6 +663,32 @@ Programming Recommendations
|
|||
continuation characters thanks to the containing parentheses. The older
|
||||
form will be removed in Python 3000.
|
||||
|
||||
- When catching exceptions, mention specific exceptions
|
||||
whenever possible instead of using a bare 'except:' clause.
|
||||
|
||||
For example, use:
|
||||
|
||||
try:
|
||||
import platform_specific_module
|
||||
except ImportError:
|
||||
platform_specific_module = None
|
||||
|
||||
A bare 'except:' clause will catch SystemExit and KeyboardInterrupt
|
||||
exceptions, making it harder to interrupt a program with Control-C,
|
||||
and can disguise other problems. If you want to catch all
|
||||
exceptions that signal program errors, use 'except StandardError:'.
|
||||
|
||||
A good rule of thumb is to limit use of bare 'except' clauses to two
|
||||
cases:
|
||||
|
||||
1) If the exception handler will be printing out or logging
|
||||
the traceback; at least the user will be aware that an
|
||||
error has occurred.
|
||||
|
||||
2) If the code needs to do some cleanup work, but then lets
|
||||
the exception propagate upwards with 'raise'.
|
||||
'try...finally' is a better way to handle this case.
|
||||
|
||||
- Use string methods instead of the string module.
|
||||
|
||||
String methods are always much faster and share the same API with
|
||||
|
|
Loading…
Reference in New Issue