Guido's argument has always been that stacktraces result because of
programming errors and it helps tracking them down. I tend to agree and find
it dangerous to start using a shortcut resulting in cryptic UNIX messages.
My complaint in the past has been that the stacktrace scares or annoys an
ordinary user, since he/she doesn't know what to do next. Guido changed the
format slightly by placing the actual error message at the end. Maybe there
should be more information to guide a user what to do with the stacktrace
(such as sending it to the developer).
Of course it never hurts to be able to turn off the stacktrace (as I pleaded
before), or better, be able to add your own information to the resulting
Also, it should be possible to restrict the size of a stacktrace. Going back
hundreds of frames doesn't make sense...
For the frozen Python scripts I produce, I use the following wrapper:
except SystemExit, value:
sys.stderr.write('\nInternal error: ' + sys.exc_type)
if type(sys.exc_value) == type(''):
sys.stderr.write(': ' + sys.exc_value)
sys.stderr.write(': ' + `sys.exc_value`)
sys.stderr.write('\nStacktrace (innermost first):')
ignore = StackTrace(sys.exc_traceback.tb_next) # Skip myself
And the actual stacktrace I produce looks as follows (I temporarily didn't
catch the KeyboardInterrupt to produce this):
Internal error: KeyboardInterrupt
Stacktrace (innermost first):
Module 'aliasTree': line 46
Module 'fileCache': line 45, line 34
Module 'aliasTree': line 271
which makes the stacktrace more compact and easier to decode for me (other
people may differ in opinion).
- Internal error indicates what it means :-)
- Using absolute pathnames to files doesn't make sense for frozen
scripts (unless dynamically created/loaded)
- Using innermost first is more intuitive for me (directly following
the error message)
- Actual lines of code (apart from being unaccessible in a frozen
program) don't seem to help that much. I always revert to the
linenumbers and look at the context in the source code.
Ramble, ramble, ramble, ramble