[Stackless] [Micro-Threads] Reliably retrieving the current exception for the current micro-thread (re-re-send)

Mike Fletcher mfletch at tpresence.com
Fri Nov 10 20:27:26 CET 2000


I've been noticing an annoying "feature" of micro-threads.  In all of my
systems, I tend to have last-resort code which prevents unhandled exits and
tries to return informative error messages before shutting down the
application.  These are simple formatted python trace backs which are
created in global "except" clauses which wrap the message handling routines.

Unfortunately, under micro-threads, the except clause using
traceback.print_exc winds up reporting the last exception that occurred in
_any_ micro-thread (including those which have been successfully caught and
handled in other micro-threads).  Since I have nonblocking socket I/O
running (which uses socket.error exceptions to indicate blocking), I tend to
get the socket error returned (which is entirely unhelpful), instead of the
informative exception for which I'm looking.

Until now, I've ignored the problem, assuming that creating an atomic error
formatter that gets called immediately after the exception occurs would
largely eliminate the problem.  It helps, but there are still times when an
exception occurs in another thread before the error formatter is called, and
I don't like the nondeterministic character (Documentation: You may see an
informative exception message, or it may just be confusing garbage).  Is
there some way that the sys.last_* stuff can get reset to the
micro-thread-local exception when we time slice a continuation?

Here is the formatter I'm currently using:
def getExceptionString():
	'''Attempt to get the "current" exception string.
	Unfortunately, there's always a chance that some
	other micro-thread has raised (and possibly caught
	another exception before you call this function.'''
	tmp = continuation_uthread_lock(1)
	try:
		io = StringIO()
		traceback.print_exc( 20, io )
		return io.getvalue()
	finally:
		continuation_uthread_lock(tmp)

Not a critical issue, but it would be nice to have some way to get a useful
trace.  Enjoy,
Mike

__________________________________
 Mike C. Fletcher
 Designer, VR Plumber
 http://members.home.com/mcfletch
_______________________________________________
Stackless mailing list
Stackless at starship.python.net
http://starship.python.net/mailman/listinfo/stackless



More information about the Stackless mailing list