sys.exit()

I

Ivan Voras

In a code such as:

if len(sys.argv) < 2:
print "I need arguments!"
sys.exit(1)

Is sys.exit() really a good choice? Is there something more elegant? (I
tried return but it is valid only in a function)
 
D

Duncan Booth

Ivan Voras said:
In a code such as:

if len(sys.argv) < 2:
print "I need arguments!"
sys.exit(1)

Is sys.exit() really a good choice? Is there something more elegant? (I
tried return but it is valid only in a function)

More elegant might be to put your code in a function which would let you
use return, although even then you need to call sys.exit somewhere if you
want to set a return code. Remember that sys.exit just throws an exception,
so you can always catch it further out if you need to. Also you can combine
the print into the call to sys.exit and save a line:

import sys

def main(args):
if len(args) < 2:
sys.exit("I need arguments!")

print "rest of program..."

if __name__=='__main__':
main(sys.argv)
 
P

Peter Hansen

Ivan said:
In a code such as:

if len(sys.argv) < 2:
print "I need arguments!"
sys.exit(1)

Is sys.exit() really a good choice? Is there something more elegant? (I
tried return but it is valid only in a function)

sys.exit() is the proper, defined, cross-platform way to exit from
a program and return a value to the calling program. Change your
definition of elegant and you could consider it easily the most elegant
of all solutions. ;-)

-Peter
 
I

Ivan Voras

sys.exit() is the proper, defined, cross-platform way to exit from
a program and return a value to the calling program. Change your
definition of elegant and you could consider it easily the most
elegant of all solutions. ;-)

Ok. :)

(Just for the record: I was looking for something that doesn't require a
module import. But it is not important.)
 
G

Gerrit Holl

Ivan said:
In a code such as:

if len(sys.argv) < 2:
print "I need arguments!"
sys.exit(1)

Is sys.exit() really a good choice? Is there something more elegant? (I
tried return but it is valid only in a function)

An alternative that I often choose is:

raise SystemExit("I need arguments!")

This is the same in one line, and I think it is more elegant, because it
is higher-level: you are not using the low-level interface of error codes,
a non-programmer may not understand what '1' means, usually it means success
so that can be very confusing. I prefer raise SystemExit.

Gerrit.

--
30. If a chieftain or a man leave his house, garden, and field and
hires it out, and some one else takes possession of his house, garden, and
field and uses it for three years: if the first owner return and claims
his house, garden, and field, it shall not be given to him, but he who has
taken possession of it and used it shall continue to use it.
-- 1780 BC, Hammurabi, Code of Law
 
I

Ivan Voras

Gerrit said:
An alternative that I often choose is:

raise SystemExit("I need arguments!")

This is the same in one line, and I think it is more elegant, because
it
is higher-level: you are not using the low-level interface of error

Yes, I agree. This is what I was looking for (as always, it was obvious
:) ), thanks. Only, what error code is returned for this termination method?
 
G

Gerrit Holl

Ivan said:
Yes, I agree. This is what I was looking for (as always, it was obvious
:) ), thanks. Only, what error code is returned for this termination method?

For a string, I believe it is 1, although I don't know when this holds and
when it doesn't - I don't care for myself, so I never tried to find out, really ;)

Gerrit.
 
G

George Young

For a string, I believe it is 1, although I don't know when this holds and
when it doesn't - I don't care for myself, so I never tried to find out, really ;)

Actually, SystemExit is a *lower* level operation. From the docs:
[ http://www.python.org/doc/current/lib/module-sys.html ]
================================================================
exit( [arg])

Exit from Python. This is implemented by raising the SystemExit
exception, so cleanup actions specified by finally clauses of try
statements are honored, and it is possible to intercept the exit
attempt at an outer level. The optional argument arg can be an integer
giving the exit status (defaulting to zero), or another type of
object. If it is an integer, zero is considered ``successful
termination'' and any nonzero value is considered ``abnormal
termination'' by shells and the like. Most systems require it to be in
the range 0-127, and produce undefined results otherwise. Some systems
have a convention for assigning specific meanings to specific exit
codes, but these are generally underdeveloped; Unix programs generally
use 2 for command line syntax errors and 1 for all other kind of
errors. If another type of object is passed, None is equivalent to
passing zero, and any other object is printed to sys.stderr and
results in an exit code of 1. In particular, sys.exit("some error
message") is a quick way to exit a program when an error occurs.
================================================================

So SystemExit is called by sys.exit. And one can use:

sys.exit('I need arguments!')

Thus it would seem that sys.exit is higher level, and probably a bit more
stable and portable.


-- George
 
G

Gerrit Holl

George said:
So SystemExit is called by sys.exit. And one can use:

sys.exit('I need arguments!')

Thus it would seem that sys.exit is higher level, and probably a bit more
stable and portable.

Ah, yes. I was probably confused with another function, I think with
os._exit. I don't really understand why _exit is in the os module
while exit is in the sys module; I have grown accostumed to raising
SystemExit, but I can de-grow it again I guess ;)

Gerrit.

--
240. If a merchantman run against a ferryboat, and wreck it, the master
of the ship that was wrecked shall seek justice before God; the master of
the merchantman, which wrecked the ferryboat, must compensate the owner
for the boat and all that he ruined.
-- 1780 BC, Hammurabi, Code of Law
 
D

Donn Cave

Quoth "Ivan Voras" <[email protected]>:
| In a code such as:
|
| if len(sys.argv) < 2:
| print "I need arguments!"
| sys.exit(1)
|
| Is sys.exit() really a good choice? Is there something more elegant? (I
| tried return but it is valid only in a function)

Your question has already been answered many times over, so I will
instead note something about the above that is rather common but
wrong. "print" writes to sys.stdout (unless instructed otherwise),
and in the present case this output should certainly go to sys.stderr.
The easiest way to do that in recent versions of python (2.0 and
later) is "print >> sys.stderr".

Donn Cave, (e-mail address removed)
 
D

Duncan Booth

Donn Cave said:
| Is sys.exit() really a good choice? Is there something more elegant? (I
| tried return but it is valid only in a function)

Your question has already been answered many times over, so I will
instead note something about the above that is rather common but
wrong. "print" writes to sys.stdout (unless instructed otherwise),
and in the present case this output should certainly go to sys.stderr.
The easiest way to do that in recent versions of python (2.0 and
later) is "print >> sys.stderr".

Note that the suggestions to use "sys.exit(message)" or "raise
SystemExit(message)" will send the message to sys.stderr. This is probably
easier than doing it explicitly in a separate print statement, plus it has
the advantage that if you want to catch the exit for any reason you also
catch the error message.

I've actually ended up doing this on occasion in unit tests, if you are
testing something that should cause a fatal error its a lot easier if the
error message is encapsulated in the SystemExit exception.
 
D

Donn Cave

Quoth Duncan Booth <[email protected]>:
....
|> Your question has already been answered many times over, so I will
|> instead note something about the above that is rather common but
|> wrong. "print" writes to sys.stdout (unless instructed otherwise),
|> and in the present case this output should certainly go to sys.stderr.
|> The easiest way to do that in recent versions of python (2.0 and
|> later) is "print >> sys.stderr".
|
| Note that the suggestions to use "sys.exit(message)" or "raise
| SystemExit(message)" will send the message to sys.stderr. This is probably
| easier than doing it explicitly in a separate print statement, plus it has
| the advantage that if you want to catch the exit for any reason you also
| catch the error message.
|
| I've actually ended up doing this on occasion in unit tests, if you are
| testing something that should cause a fatal error its a lot easier if the
| error message is encapsulated in the SystemExit exception.

That's right, it does work and it is easier. But please don't think
of print >> sys.stderr as something that's hard, lest that lead to
code like distutils that just neglects to do it.

distutils perhaps has the excuse that it had this problem before there
was a solution, but it's a good example of the problem. It's natural
to want to save the output of distutils to disk - I think it's really a
good practice to do this routinely so later you know how an application
was built, what went into it and where it got installed. In this case,
you'd always redirect both stdout and stderr, with a shell command line
like 'python setup.py > make.log 2>&1', so it would seem that the choice
between stdout and stderr would not matter. But it matters a lot, because
when stdout is a disk file, it's block buffered. That means the actual
flush to disk may be deferred for some time. Meanwhile, the applications
and processes that distutils invokes (cc, etc.) write immediately to disk
because if nothing else their output buffers flush when they exit. So
your log file starts with a bunch of diagnostic output from cc, and only
later gets to the distutils output that announces it's going to run cc.
Completely unreadable. stderr is always line buffered.

Donn Cave, (e-mail address removed)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,166
Messages
2,570,907
Members
47,448
Latest member
DeanaQ4445

Latest Threads

Top