On 19Aug2014 16:41, Terry--gmail <terry.kemme...@gmail.com> wrote:
The bare 'except' was a throw away. By bare 'except' I am assuming you mean
without defining the type of error 'except' is to act upon?
try:
something
except ValueError:
do something
-Or does bare 'except' mean something else?
You're right, it means "except" with no exception type.
The trouble with bare excepts is that they catch every exception, not just the
one you expected to get. For example, this code:
x = 1
y = 2
z = xx + y
would raise a NameError because "xx" is unknown. To my mind and yours it is
just a typo, but in a dynamic language like Python this is only detected at
runtime. If that code were inside a bare try/except then you might spent a very
long time figuring out what was wrong because you're expecting one kind of
failure be getting another.
As general practice, the rule of thumb is that you should make "except"s as
precise as possible and only handle errors you explicitly expect and know what
to do with.
An example from some of my code:
try:
arfp = open(arpath)
except OSError as e:
if e.errno == errno.ENOENT:
arfp = None
else:
raise
Here I'm catching the expected possibility that the file I'm opening does not
exist and setting arfp to None. Any other type of problem (permission denied,
etc) continues on to raise an exception.
While this makes you code fragile in one sense, it prevents it _silently_
misinterpreting one thing as another, and that is usually best.
Cheers,
Cameron Simpson <c...@zip.com.au>
The aim of AI is to make computers act like the ones in the movies.
- Graham Mann
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
