more informative stack traces
Anders J. Munch
andersjm at dancontrol.dk
Mon Apr 14 15:27:26 CEST 2003
"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.
More information about the Python-list