nmm1 at cus
Mar 2, 2007, 1:02 PM
Post #3 of 4
(326 views)
Permalink
|
|
except Exception as err, tb [was: with_traceback]
[In reply to]
|
|
"Jim Jewett" <jimjjewett [at] gmail> 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
Tel.: +44 1223 334761 Fax: +44 1223 334679
_______________________________________________
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
|
