[Python-Dev] PEP 352 Transition Plan

[Brett Cannon]

On 10/28/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
> > Interesting point, but I think that chaining should have more concrete
> > support ala PEP 344 or some other mechanism.  I think most people
> > agree that exception chaining is important enough to have better
> > support than some implied way of a causing exception to be passed
> > along.  Perhaps something more along the lines of:
> >
> >   try:
> >       raise TypeError("inner detail")
> >   except TypeError, e:
> >       raise TypeError("outer detail", cause=e)
> >
> > where BaseException then has a 'cause' attribute that is set to None
> > by default or some specific object that is passed in as the second
> > argument to the constructor.
>
> Another point in PEP 352's favour, is that it makes it far more feasible to
> implement something like PEP 344 by providing "__traceback__" and
> "__prev_exc__" attributes on BaseException.
>
> The 'raise' statement could then take care of setting them appropriately if it
> was given an instance of BaseException to raise.
>

Yep.  This is why having a guaranteed API is so handy for exceptions. 
And actually PEP 3000 says that exceptions are supposed to gain a
traceback attribute.  But that can be another PEP if PEP 344 doesn't
make it.

> Actually, that brings up another question - PEP 352 says it will require
> objects that "inherit from BaseException". Does that mean that either subtypes
> or instances of BaseException will be acceptable? Or does it just mean
> instances? If the latter, how will that affect the multi-argument forms of
> 'raise'?
>

I don't see how a multi-argument 'raise' changes the situation any. 
``raise BaseException`` and ``raise BaseException()`` must both be
supported which means isinstance() or issubtype() will be used (unless
Python 3 bans raising a class or something).

-Brett

-Brett