[Python-Dev] except Exception as err, tb [was: with_traceback] (original) (raw)

Nick Maclaren nmm1 at cus.cam.ac.uk
Fri Mar 2 22:02:22 CET 2007

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

Guido van Rossum wrote:

> Since this can conceivably be going on in parallel in multiple > threads, we really don't ever want to be sharing whatever object > contains the head of the chain of tracebacks since it mutates at every > frame bubble-up. So (full) exceptions can't be unitary objects. In theory, raising an already-instantiated instance could indicate "no traceback", which could make pre-cooked exceptions even lighter.

Grrk. I think that this is right, but the wrong way to think of it!

If we regard a kind of exception as a class, and an actual occurrence as an instance, things become a lot cleaner. The class is very simple, because all it says is WHAT happened - let's say divide by zero, or an attempt to finagle an object of class chameleon.

The instance contains all of the information about the details, such as the exact operation, the values and the context (including the traceback). It CAN'T be an object, because it is not 'assignable' (i.e. a value) - it is inherently bound to its context. You can turn it into an object by copying its context into an assignable form, but the actual instance is not assignable.

This becomes VERY clear when you try to implement advanced exception handling - rare nowadays - including the ability to trap exceptions, fix up the failure and continue (especially in a threaded environment). This makes no sense whatsoever in another context, and it becomes clear that the action of turning an instance into an object disables the ability to fix up the exception and continue. You can still raise a Python-style exception (i.e. abort up to the closest handler), but you can't resume transparently.

I have implemented such a system, IBM CEL was one, and VMS had/has one. I don't know of any in the Unix or Microsoft environments, but there may be a few in specialised areas.

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".

Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1 at cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

More information about the Python-Dev mailing list