more informative stack traces

Scott Chapman scott_list at mischko.com
Mon Apr 14 23:03:08 CEST 2003


On Monday 14 April 2003 06:27, Anders J. Munch wrote:
> "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.

Any possibility of getting this idea to be part of Python? It seems like the 
Right Thing to me.  It could be made user-configurable (on or off) so that 
backward compatibility could be maintained.

Scott






More information about the Python-list mailing list