else: w/o except: - why not?

David Bolen db3l at fitlinxx.com
Thu Apr 3 10:37:18 EST 2003


Michael Chermside <mcherm at mcherm.com> writes:

> The other situation is running "untrusted plug-in" code of some 
> sort. Something like this:
> 
>     try:
>         randomCodeSomebodyUploaded()
>     except:
>         logProblem()
> 
> But really, that hardly EVER comes up. I wish that guido had made
> it harder to spell "bare except" because these situations seem so
> unusual. The next best solution is to just avoid it unless you're
> SURE you need it.

I think you need to be careful about blanket statements like "hardly
EVER" - it really depends on the sort of target environment being
worked on.  In our case for example, a large amount of our Python code
deals with distributed systems management and communications, and
there are quite a few cases where we have bare excepts in order to
catch any exceptions to be packaged and either reported (as part of a
plugin or dynamic module system as you show above), propagated to some
client, or just logged and execution resumed.  In such cases I
consider it a perfectly good programming practice and in fact one of
the conveniences of Python to ensure an application stays operational.

Now, in other cases with applications that are more standalone or
non-infrastructure related, it is in fact much rarer to need such a
construct, although even there I'll often have at least one such case
per production application near the uppermost code levels as a general
purpose trap to log unexpected failures but permit the application to
resume operation at some initialized point.

To be honest, the only thing we've had to be careful of in such cases
is with respect to the prior comments about possibly not wanting to
catch KeyboardInterrupt or SystemExit.  But we've found it easier to
check and re-raise those in the bare except clause, than to try to
come up with a qualified except clause that includes all other
exceptions.  We did try using "except Exception" instead but that
won't catch older string exceptions which are still used by some
modules we use.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/




More information about the Python-list mailing list