I got that, but I failed (and still fail) to see what pertinence a bug
in os.py has to do with the semantics of sys.exit()... Let's drop
this silly argument, OK!
> I wouldn't care about the stack trace so much if the format wasn't so
> confusing to the ordinary user (yes, other people than myself are using
> python programs). Maybe, if the error message could be called out more
> and the stack trace could be preceded with some disclaimer, it wouldn't
> be so confusing to the ordinary user. They complain to me: WHAT IS
> HAPPENING??? as where the fault is e.g. disk full or something else
> that I don't check for (is that a bug??? Can't check for everything...)
> and they can't seem to find the actual problem in all the output.
Excuse me, but it's obvious that the bug is in your program. (Half
:-) Read any good, recent book on user interfaces and you'll find that
it is unacceptable for users if a program fails with a cryptic error
message. I bet that a short cryptic error message (just the exception
name) isn't any better than a long one (which includes the stack
trace) since in both cases it's communicating at the wrong level, as
far as the user is concerned. (And note that a C program would
probably have failed silently in the case of disk full, unless there
was an explicit check at every write call! Do you like that better?)
However, I should take my part of the blame too: it is true that when
the stack trace is long the exception type is hard to find. I'll
experiment with placing the exception message *after* the stack trace
instead of before it.
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>