[Python-Dev] except Exception as err with tb [was: with_traceback] (original) (raw)
Jim Jewett jimjjewett at gmail.com
Fri Mar 2 23:44:38 CET 2007
- Previous message: [Python-Dev] Another traceback idea [was: except Exception as err, tb]
- Next message: [Python-Dev] PEP 344 (was: with_traceback)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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" 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
- Previous message: [Python-Dev] Another traceback idea [was: except Exception as err, tb]
- Next message: [Python-Dev] PEP 344 (was: with_traceback)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]