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

[Brett Cannon]

On 7/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.
>

I can live with this.  I was waivering on putting ControlFlowException
under CriticalException, but obviously keeping that dichotomy was more
important back when bare 'except' clauses were going to be allowed,
but now that it looks like they are being removed I am much more open
to putting stuff to inherit directly from Raisable.
 
> >         +-- 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:
> 
>    try:
>      yield itr.next()
>    catch StopIteration:
>      pass
> 

Good enough for me.

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

It looks like the backwards-compatilibity gods are starting to stomp
on me; I can sacrifice a renaming to appease them.

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

Hmm.  Well, I think it was either Tim or Barry (or both) who once
suggested AttributeError inherit from TypeError, but they have not
spoken up nor has anyone else so far supporting the idea.

But then again people have argued for LookupError instead.  I am going
to have to think about this one before I attempt to reply on this
topic.

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

OK, but is the name so great?  Yes, it is a runtime error, but it just
doesn't hit the point of it being a dirty little exception to use when
you don't want to create a new one.  How about GenericException or
SimpleException?

Or are the backwards-compatibility gods going to smack me again for
this suggestion and spout something off containing the words "not" and
"Perl 6"?  =)

> > 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:
> 
> http://dictionary.reference.com/search?q=raisable
> 

I think the point was it was not in someone's spell checker.  But I
consider this point settled since Guido said he was fine with creating
a new 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.
> 

This seems to be the running consensus so far.  I am expecting bare
'except' clauses to not be allowed.

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

Fine by me.  I only tossed that in since originally people were
suggesting BaseException or SafeException and the ilk.

-Brett