RetroSearch Browse

Tue Sep 7 16:13:51 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-September/048648.html

On Tue, 2004-09-07 at 09:43, Jim Fulton wrote:

> Note that we don't want uncatchable exceptions. Rather, we want
> exceptions that aren't caught by bare excepts or very broad
> excepts.  In many cases, we want certain knowledgeable code to be able
> to catch these exceptions.

I don't agree about having exceptions that pass bare excepts.  A typical
/valid/ use of bare excepts are in frameworks such as transaction
processing, where you need to do some extra work when an exception
occurs, then re-raise the original exception, e.g.:

try:
    do_something()
except:
    database.rollback()
    raise
else:
    database.commit()

Even exceptions like SystemError, MemoryError, or KeyboardInterrupt want
to adhere to this simple idiom.  Bare except should continue to catch
all exceptions.  Code that wanted to do otherwise should /not/ use a
bare except, and +1 on some form of exception hierarchy restructuring
that would make that clearer.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040907/3512c996/attachment.pgp

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-September/048648.html below:

[Python-Dev] Re: Dangerous exceptions (was Re: Another test_compilermystery)