RetroSearch Browse

Tue Sep 7 16:44:17 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-September/048651.html

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:
>     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.

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

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

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

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