[Python-Dev] PEP 348: Exception Reorganization for Python 3.0

Guido van Rossum gvanrossum at gmail.com
Fri Aug 5 22:16:31 CEST 2005

On 8/5/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> While I agree with most of your -1's on gratuitous changes, this particular
> problem isn't gratuitous.  A StopIteration that reaches a regular exception
> handler is a programming error; allowing StopIteration and other
> control-flow exceptions to be caught other than explicitly *masks*
> programming errors.

And your point is? If that was the reasoning behind this PEP, it
should move TypeError, NameError, AttributeError and a whole bunch of
others (even LookupError) out of the StandardError hierarchy too!
Those are all clear symptoms of programming errors and are frequently
masked by bare 'except:'.

The point is not to avoid bare 'except:' from hiding programming
errors. There's no hope to obtain that goal.

The point is to make *legitimate* uses of bare 'except:' easier -- the
typical use case is an application that has some kind of main loop
which uses bare 'except:' to catch gross programming errors in other
parts of the app, or in code received from an imperfect source (like
an end-user script) and recovers by logging the error and continuing.
(I was going to say "or clean up and exit", but that use case is
handled by 'finally:'.)

Those legitimate uses often need to make a special case of
Keyboardinterrupt and SystemExit -- KeyboardInterrupt because it's not
a bug in the code but a request from the user who is *running* the app
(and the appropriate default response is to exit with a stack trace);
SystemExit because it's not a bug but a deliberate attempt to exit the
program -- logging an error would be a mistake.

I think the use cases for moving other exceptions out of the way are
weak; MemoryError and SystemError are exceedingly rare and I've never
felt the need to exclude them; when GeneratorExit or StopIteration
reach the outer level of an app, it's a bug like all the others that
bare 'except:' WANTS to catch.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list