A RetroSearch Logo

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

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-August/055172.html below:

Exception Reorganization for Python 3.0

[Python-Dev] PEP 348: Exception Reorganization for Python 3.0 [Python-Dev] PEP 348: Exception Reorganization for Python 3.0Reinhold Birkenfeld reinhold-birkenfeld-nospam at wolke7.net
Fri Aug 5 22:12:31 CEST 2005
Raymond Hettinger wrote:

> 2.  There is a lesson to be taken from a story in the ACM risks forum
> where a massive phone outage was traced to a single line of C code that
> ran a "break" to get out of a nested if-statement.  The interesting part
> is that this was known to be mission critical code yet the error
> survived multiple, independent code reviews.  The problem was that the
> code created an optical illusion.  We risk the same thing when an
> "except Exception" doesn't catch ControlFlowExceptions.  The
> recovery/logging handler will look like it ought to catch everything,
> but it won't.  That is a disaster for fault-tolerant coding and for
> keeping your sales demo from exploding in front of customers.

I think that ControlFlowException should inherit from Exception, because it is
an exception. As Raymond says, it's hard to spot this when in a hurry.

But looking at the current PEP 348, why not rename BaseException to Exception
and Exception to Error?

That way, you could say "except Error:" instead of most of today's bare "except:"
and it's clear that StopIteration or GeneratorExit won't be caught because they
are not errors.

Reinhold


-- 
Mail address is perfectly valid!

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4