[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0

[Brett Cannon]

On 8/3/05, Michael Hudson <mwh at python.net> wrote:
> Guido van Rossum <gvanrossum at gmail.com> writes:
> 
> > So here's a radical proposal (hear the scratching of the finglernail
> > on the blackboard? :-).
> >
> > Start with Brett's latest proposal. Goal: keep bare "except:" but
> > change it to catch only the part of the hierarchy rooted at
> > StandardError.
> >
> > - Call the root of the hierarchy Raisable.
> > - Rename CriticalException to CriticalError
> >   (this should happen anyway).
> > - Rename ControlFlowException to ControlFlowRaisable
> >   (anything except Error or Exception).
> > - Rename StandardError to Exception.
> > - Make Warning a subclass of Exception.
> >
> > I'd want the latter point even if the rest of this idea is rejected;
> > when a Warning is raised (as opposed to just printing a message or
> > being suppressed altogether) it should be treated just like any other
> > normal exception, i.e. StandardError.
> 
> In the above you need to ensure that all raised exceptions inherit
> from Raisable, because sometimes you really do want to catch almost
> anything (e.g. code.py).
> 

That's part of the PEP.

> Has anyone thought about the C side of this?

I have thought about it somewhat, but I have not dived in to try to
write a patch.

>  There are a few
> slightly-careless calls to PyErr_Clear() in the codebase, and they can
> cause just as much (more!) heartache as bare except: clauses.
> 

I fail to see how clearing the exception state has any effect on the
implementation for the PEP.

> I'll note in passing that I'm not sure that any reorganization of the
> exception hierachy will make this kind of catching-too-much bug go
> away.  The issue is just thorny, and each case is different.
> 

It will never go away as long as catching exceptions based on
inheritance exists.  Don't know if any language has ever solved it. 
Best we can do is try to minimize it.

> I'm also still not convinced that the backwards compatibility breaking
> Python 3.0 will ever actually happen, but I guess that's a different
> consideration...

Perhaps not.  Might end up doing so much of a slow transition that it
will just be a bigger codebase change from 2.9 (or whatever the end of
the 2.x branch is) to 3.0 .

> --
>   Haha! You had a *really* weak argument! <wink>
>                                       -- Moshe Zadka, comp.lang.python

Hopefully I don't.  =)

-Brett