[Python-Dev] Re: Dangerous exceptions (was Re: Another test_compilermystery) (original) (raw)
Jim Fulton jim at zope.com
Tue Sep 7 16:44:17 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 ]
Barry Warsaw wrote:
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: dosomething() 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.
Fair enough.
I also agree with jeremy's points re backward compatability.
Jim
-- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
- 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 ]