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

Nick Coghlan ncoghlan at gmail.com
Sat Jul 30 10:13:31 CEST 2005

Brett Cannon wrote:
>     +-- ControlFlowException (new)

While I like the idea of ControlFlowException as the "one obvious way" to 
break out of multiple nested loops, I'm not convinced StopIteration and 
GeneratorExit should be inheriting from it.

However, I'm even less sure StopIteration and GeneratorExit should be in the 
Exception portion of the hierarchy at all. This is particularly true of 
GeneratorExit - I would be very concerned if "except Exception:" were to 
suppress GeneratorExit. If ControlFlowException was moved up to be a peer of 
Exception, I'd be much happier with the idea - we would then have four major 
categories of raisable classes:
   CriticalException - something is seriously wrong
   ControlFlowException - an exception is being used to affect control flow in 
a particular way, and should be intercepted only if you know what that control 
flow is doing
   Exception - your every day, run of the mill, exceptions
   Warning - not really an exception.

>         +-- GeneratorExit (introduced by PEP 342 [PEP342]_; subclass
> StopIteration?)

Definitely not. GeneratorExit was added because the following idiom prevents 
the use of StopIteration or a subclass to reliably terminate a generator:

     yield itr.next()
   catch StopIteration:

>     +-- LookupError (better name?)
>         +-- IndexError
>         +-- KeyError

I don't think there is a particularly strong argument to change the name of 
LookupError. While Py3K *allows* backwards incompatibility, we shouldn't be 
gratutitous about it.

>     +-- TypeError
>         +-- AttributeError (subclassing new)
>     +-- NamespaceException (new)
>         +-- UnboundGlobalError (new name for NameError)
>         +-- UnboundLocalError (no longer subclasses UnboundGlobalError
> which replaces NameError)

I'd actually be inclined to make AttributeError a subclass of NameError:

   +-- NameError
       +-- AttributeError (subclassing new)
       +-- UnboundGlobalError (new)
       +-- UnboundLocalError

Current uses of NameError are replaced with UnboundGlobalError. The re-use of 
NameError reduces the backwards incompatibility, and also concisely summarises 
the common feature of these three exceptions.

> RuntimeError
> ''''''''''''
> Meant to be used when an existing exception does not fit, its
> usefulness is consider meager in Python 2.4 [exceptionsmodule]_.
> Also, with the CriticalException/Exception dichotomy, Exception or
> CriticalException can be raised directly for the same use.

Like Guido, I believe RuntimeError is very useful for quick-and-dirty scripts. 
Also, gratuitous incompatibility should be avoided, even for Py3k.

> Change the Name of Raisable?
> ----------------------------
> It has been argued that Raisable is a bad name to use since it is not
> an actual word [python-dev1]_.
> At issue is choosing a name that clearly explains the class' usage.
> "BaseException" might be acceptable although the name does not quite
> make it as explicit as Raisable that the class is not meant to be
> raised directly.

I like Raisable, because it states exactly what the base class indicates: 
something which can be raised (i.e., used with the "raise" statement). I'm 
also unclear on why anyone would say it isn't an actual word:


> Should Bare ``except`` Clauses be Removed?
> ------------------------------------------
I think Explicit Is Better Than Implicit for this one - a bare except which is 
not the equivalent of "except Raisable" would be quite confusing.

So long as the tutorial says that anything broader then "except Exception" is 
going to be wrong 99.9% of the time, I don't think there will be a problem.

> Change the name of Exception?
> -----------------------------

Again, there is a strong backwards compatibility argument for keeping the name 
Exception for the "this is what you should normally catch" category. Mainly, 
there's a lot of code out there that already uses it this way. Without a 
compelling argument in favour of a different name, stick with Exception.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list