try..except with empty exceptions
cs at zip.com.au
Sun Apr 12 08:47:05 CEST 2015
On 12Apr2015 14:18, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>On Sun, 12 Apr 2015 09:08 am, Cameron Simpson wrote:
>> Also, IMO, a bare "except:" syntax is far more pleasing to the eye than
>> "except magic_exception_name_that+gets_everything:".
>And that is exactly what makes bare excepts an attractive nuisance!
>I'm going to channel a newbie, cowboy or just plain lazy coder:
>"I have a block of code with a bug. Bugs are bad. I know, I'll wrap it in
>and the bug will go away!"
And haven't we all seen that _many_ times on this list:-)
>It looks nice and requires relatively little typing. It seems like something
>you should do, but it doesn't fix the problem, chances are it just makes it
And do not get me started on Makefiles which finish every compile command in
>I've spotted many real-world examples where bare excepts mask the
>presence of actual bugs, where the intention is clearly to catch a single
>Forcing people to type an exception will discourage such cowboy coding. If
>the choice is between
> except BaseException:
>instead of the lazy "except:" version, and
> except IndexError:
>which do you think people will write?
I fear that the just-beyond-beginner might write "Exception", but your point is
>> Also, I wish
>> "BaseException" were just spelled "Exception", if it has to be used.
>Most of the time, "catch everything" should mean catching Exception, not
>BaseException. Broadly speaking, built-in exceptions which are
>considered "errors" inherit from Exception, and the small number that don't
>are used for some variation of control-flow:
>Most of the time when people say "catch everything" they mean catch all
>errors, i.e. Exception, rather than "don't let the user interrupt the code
Yes, I see that this is true.
And I have special pain in some of my code which then causes me to specificly
catch NameError ahead of my bare (or mostly bare) excepts because that usually
indicates some stupid typo on my part, causing silent breakage and debugging
>See also PEP 352:
Thank you for this.
Cameron Simpson <cs at zip.com.au>
To be or not to be? Not to be.
- John Slater (Arnold Schwartzenegger),
More information about the Python-list