no.email at please.post
Fri Aug 6 13:23:50 CEST 2010
In <pan.2010.07.23.21.46.03.547000 at nowhere.com> Nobody <nobody at nowhere.com> writes:
>On Fri, 23 Jul 2010 10:42:26 +0000, Steven D'Aprano wrote:
>> Don't write bare excepts, always catch the error you want and nothing
>That advice would make more sense if it was possible to know which
>exceptions could be raised. In practice, that isn't possible, as the
>documentation seldom provides this information. Even for the built-in
>classes, the documentation is weak in this regard; for less important
>modules and third-party libraries, it's entirely absent.
I don't get your point. Even when I *know* that a certain exception
may happen, I don't necessarily catch it. I catch only those
exceptions for which I can think of a suitable response that is
*different* from just letting the program fail. (After all, my
own code raises its own exceptions with the precise intention of
making the program fail.) If an unexpected exception occurs, then
by definition, I had no better response in mind for that situation
than just letting the program fail, so I'm happy to let that happen.
If, afterwards, I think of a different response for a previously
uncaught exception, I'll modify the code accordingly.
I find this approach far preferable to the alternative of knowing
a long list of possible exceptions (some of which may never happen
in actual practice), and think of ways to keep the program still
alive no-matter-what. "No memory? No disk space? No problem!
Just a flesh wound!" What's the point of that?
(If I want the final error message to be something other than a
bare stack trace, I may wrap the whole execution in a global/top-level
try/catch block so that I can fashion a suitable error message
right before calling exit, but that's just "softening the fall":
the program still will go down.)
More information about the Python-list