No, originally sys.exit() would just call the C routine exit(). There
were complaints about this and I changed it into an exception so that
finally clauses would work. (There is no way to execute them except
by letting the stack unwind itself.)
Also the exception makes it possible for a debugger or similar package
to trap sys.exit() without patching up the sys module.
> | code. Nobody in their right mind would use posix._exit(n) except to
> | exit from a forked child, but lots of code may call sys.exit(n) -- as
>
> True, still, os.py is broken on DOS.
Then fix os.py! (This particular bug will be fixed in the next
release.)
Note that os.py also assigns sep = '/' which you probably don't want
under DOS, although I think it does work; should I fix it? (I think
it should also set name = 'dos' or perhaps 'msdos'.)
Under DOS the _exit() function shouldn't be in os since it isn't in
the C library either. (Or is it? Then maybe I should add it to the
DOS version of the posix interface... Please enlighten me, I always
thought that _exit() is specific to real UNIX and not specified by
Standard C.)
> | Code that uses an unqualified except clause is always suspect. It may
> | mask exceptions caused deep inside that you didn't know were possible,
> | such as SystemError, MemoryError or TypeError in code that you thought
> | had no bugs.
>
> Yes, I know. Listing all exceptions I want to catch in separate lines,
> yet all of them using the same code, is a hassle (especially if there
> are quite a few of them). Couldn't we add something that would allow
> you to pass a list of exception types as the first argument to
> except:?
You can already do this! (I believe it has always been possible and
is even documented in the reference manual.)
try:
"some code"
except (ex1, ex2, ex3), value:
"handler for three different exceptions"
> Also, the whole stacktrace is a hassle. It is great for the developer,
> but confusing for the ordinary user that doesn't care for it
> (espacially if the python program is a subprogram of another program).
> That's why often I wrap the whole program in a try: except:, forgoing
> the stacktrace, but printing the problem (using the exc_type and
> exc_value).
I would imagine that the vast majority Python scripts are only ever
run by their author, so having a stack trace by default makes sense.
If your script is bugfree, it should never print a stack trace. If it
does generate an exception, the user can show (or mail) the stack
trace to the author of the script who can then find the bug. Printing
only the exception would make this much harder. I don't understand
why you say that the ordinary user doesn't care: the program failed to
do what it should, so they have every right to complain!
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>