[Tutor] Using sys.exit()

Luke Paireepinart rabidpoobear at gmail.com
Thu Nov 2 10:21:42 CET 2006


>
> Yes, I realize that. But what if I'm not doing anything after the 
> loop? In that case is there anything wrong with using break to end the 
> script? I'm getting the idea from the responses that there IS 
> something wrong, but I don't see what it is.
Generally, something that exits with a break would be a normal exit case 
for a loop.  An exception would be an abnormal exit case.
Like...

while 1:
    x = raw_input('choice? "hi",  "exit"  ')
    if x == 'exit':
       break
    elif x == 'hi':
       print "Hello!"
    else:
       raise SystemExit

see, it only raises the error if the user inputs an invalid value.
>
>> A SystemExit immediately ends the program at that call
>> (unless you catch the exception :)
>>
>> The reason the exits with break are 'silent'
>> is because no exceptions are occurring.
>
> But that's exactly what I want--a silent exit.
So don't use exceptions then.
The point of exceptions is so that there's a traceback that the 
developer can see and
use to debug.
If that's not what you're trying to do, don't use an exception.

I never read your original code, so I'm not sure what you were doing,
and there may be other factors that the other Tutor subscribers felt 
contributed to the
decision of using SystemExit over break.
Just remember, SystemExit will always exit your program where you tell 
it to,
and depending on not having code after your loops so that it's not executed
when you break is probably a 'bad idea.'

>
>> SystemExit is an exception.
>> There's nothing wrong with using it.
>> You could raise an IOError if you wanted.
>
> Please explain how to do that, and why I would want to.
How to do it:
raise IOError

why?
No reason.
I was just pointing out that it doesn't particularly matter that you're 
raising a SystemExit.
Your program will terminate at any exception that's raised, and you will 
get an identical traceback.
The only reason you want to use SystemExit, is so that if someone else 
is using your function, they can capture the
SystemExit (with an except: statement) and do something with it.
An example of this would be, if you had the function

def convert_to_int(astr):
    for item in astr:
       if item.isalpha() == True:
          raise SystemExit
    return int(astr)

and I wanted to use it to convert user input to an integer,
I'd do

try:
    a = convert_to_int(raw_input('please enter an integer: '))
except SystemExit:
    print "You entered some alpha characters!"

Note that ValueError would be more appropriate here, instead of SystemExit.
Also note the function doesn't check for characters that aren't alpha or 
numbers, so a $ will pass our item.isalpha() test,
and when the function attempts to return int(astr) the int call will 
raise a ValueError.

Obviously, it would be less helpful if everything just raised one type 
of error, so that's why there's different types.
It's up to you to standardize their usage, though.  You can write 
classes that raises ValueErrors whenever anything goes
wrong, but why would you want to?
Remember, Python expects that the developer will be responsible.  It 
won't keep you from shooting yourself in the foot.
So try to raise reasonable exceptions.

I think SystemExit may have some extra magic, and it's not just a normal 
exception,
but I'm not sure about this.  Someone else know?

HTH,
-Luke


More information about the Tutor mailing list