[Python-Dev] except Exception as err with tb [was: with_traceback]

[Jim Jewett]

Proposal changed from "err, tb" to "err with tb" at Brett's good suggestion.

The rest of this message is a bit of a sidetrack; skimmers can stop now.

Nick Maclaren wrote:

>"Jim Jewett" <jimjjewett at gmail.com> wrote:
>> Guido van Rossum wrote:

>> > [multiple threads => don't share] whatever object
>> > contains the head of the chain of tracebacks

>> So (full) exceptions can't be unitary objects.

As Shane pointed out[1], the *traceback* could be a unitary object
holding all three pieces of information.  The problem is that we don't
want every except clause adding boilerplate to get the exception back
out.

[1] http://mail.python.org/pipermail/python-dev/2007-February/071417.html

>> In theory, raising an already-instantiated instance could indicate "no
>> traceback", which could make pre-cooked exceptions even lighter.

> The instance contains all of the information about the details, such
> as the exact operation, the values and the context (including the
> traceback).  ...
> ... the action of turning an instance into an object disables
> the ability to fix up the exception and continue. ...
> I don't know of any in the Unix or Microsoft environments, but
> there may be a few in specialised areas.

Lisp does it.  The cost is that instead of dying, those frames become
a continuation, and you need to keep around lots of extra (probable)
garbage.

Dealing with this cleanly was (once upon a time) one of the advantages
of Stackless Python.  Unfortunately, extension modules can call back
into python from the middle of a C function, so the clean restarting
was largely limited to pure python frames; trying to get as close as
possible for other code made the implementation fairly complicated.

> Harking back to your point, your "already-instantiated instance"
> is actually an object derived directly from the exception class, and
> everything becomes clear.  Because it is an object, any context it
> includes was a snapshot and is no longer valid.  In your case, you
> would want it to have "context: unknown".

Rather, I want "context: irrelevant" so it won't bother to keep the
context alive.

That is clearly the right thing for a normal StopIteration.  It isn't
the right thing for all pre-instantiated exceptions.  Whether it is
the right thing often enough to ask those others to use the typical
idiom -- maybe.

-jJ