On 12Apr2015 14:18, Steven D'Aprano <steve+comp.lang.pyt...@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
try:
block
except:
pass
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
worse.
And do not get me started on Makefiles which finish every compile command in
"2>/dev/null" :-(
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
exception: [...]
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
well taken.
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:
StopIteration
GeneratorExit
KeyboardInterrupt
SysExit
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
using KeyboardInterrupt".
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
hell. Ghastly.
See also PEP 352:
http://www.python.org/dev/peps/pep-0352/
Thank you for this.
Cheers,
Cameron Simpson <c...@zip.com.au>
To be or not to be? Not to be.
- John Slater (Arnold Schwartzenegger),
_Macbeth_ (_The_Last_Action_Hero_)
--
https://mail.python.org/mailman/listinfo/python-list
