>
> 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
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
