jimjjewett at gmail
Mar 2, 2007, 2:44 PM
Post #1 of 1
(220 views)
Permalink
|
|
except Exception as err with tb [was: with_traceback]
|
|
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
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
