more informative stack traces

[L.C.]

You are correct, and I underestimated the number of people using Python 
on Windows :) I'll try to add a registration mechanism for output control 
and make syslog and stdout registered clients to it, so that Windows will 
at least have stdout working. I'll repost the link when done.

Just as a historical note, this code was written at our company to solve 
the problem of exception reporting in daemon-type programs, on Linux, with
minimal impact on the main code base. So once it did that, it was kind of
frozen that way :)

--
L.C. (Laurentiu C. Badea)

"Anders J. Munch" <andersjm at dancontrol.dk> wrote in message news:<3e9ab723$0$66212$edfadb0f at dread11.news.tele.dk>...
> "L.C." <deja-google at wotevah.com> wrote:
> > I am proposing a different style of stack trace which I found more 
> > useful in debugging problems with live code. The main change involves
> > showing the actual parameter values in function calls, gdb-style.
> > It sounds simple because it really is, but it saves lots of guesswork
> > when navigating through the stack to see what caused a problem.
> > 
> > An implementation is available here: http://www.wotevah.com/code/log.py
> > To enable, just import it in your main program.
> > 
> > It requires syslog (thus Unix-only) because it seemed to be the natural
> > mechanism for reporting errors and warnings, although it will also use 
> > stderr if you are on a terminal.
> 
> May I suggest you refactor your code into two modules: a
> platform-independent one that inspects tracebacks and generates the
> traceback text in some sort of container or generator.  And a
> syslogging module one with the same interface as you have now, which
> is a client of the first module.  And perhaps a third module, a client
> that uses portable stderr output.
> 
> Not only will this give you a fighting chance of convincing people on
> syslog-less platforms of the merits of your approach, but it will also
> benefit the structure of your code.  Hardwiring the output mechanism
> puts obstacles in the way of applications such as CGI scripts and GUI
> traceback presenters, where consoles and logfiles may be irrelevant
> because user interaction goes through other channels.
> 
> - Anders