I can't disagree very hard; the current behavior of Python is extremely
useful. What's more, Jaap's boilerplate is only 23 lines long, so it isn't
too great a trial to have to hand-include something like it in every program
I ever write.
Nonetheless, I don't think the current default behavior is entirely suitable
for final delivered programs. If a user tries to cat(1) a file that doesn't
exist, they don't really want to see a stack backtrace; they want to see a
perror(3) with the name of the offending file, and what's wrong.
But now I see the big defect in my idea; the current behavior is absolutely
appropriate for ``can't happen'' problems, i.e. programmer errors. It's just
wrong for user errors. How about if I revise my proposal.
I'd like for Python to handle certain exceptions differently by default. In
particular, when IOError or MemoryError is raised with no handler, and pops
all the way up to the top level, I'd like Python, by default, to print a
compact error message after the style of perror(3), rather than a full
backtrace. It might also be useful to be able to get the full backtrace if -D
or some such is specified, to simplify debugging, but I think the current
default for these exceptions isn't suitable for production code. And I do
consider it a (mild) language defect when you always have to include chunks
of your own code in every program you write, to correct inappropriate
behavior.
-Bennett
bet@sbi.com
P.S. Are there any other exceptions I've missed, or are IOError and
MemoryError the exhaustive list of exceptions raised due to environmental
problems as reported by syscalls?