[Python-Dev] Re: Dangerous exceptions (was Re: Another test_compilermystery) (original) (raw)
Barry Warsaw barry at python.org
Tue Sep 7 16:13:51 CEST 2004
- Previous message: [Python-Dev] Re: Dangerous exceptions (was Re: Another test_compilermystery)
- Next message: [Python-Dev] Re: Dangerous exceptions (was Re: Another test_compilermystery)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Re: Dangerous exceptions (was Re: Another test_compilermystery)
- Next message: [Python-Dev] Re: Dangerous exceptions (was Re: Another test_compilermystery)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]