I don't get why sys.exit(1) doesn't exit the while loop in the follow case

[chad]

Given the following..

#!/usr/bin/python

import urllib2
import sys
import time

while 1:
try:
con = urllib2.urlopen("http://www.google.com")
data = con.read()
print "connected"
#The loop doesn't exit if I use sys.exit(1)
break
except:
time.sleep(2)


If I would replace 'break' with 'sys.exit(1)', the while loop will
keep printing connected every 2 seconds? Why I this? I thought exit
meant exit.

 

[Justin Ezequiel]

your bare except is catching the SystemExit raised by sys.exit(1)

 

[Terry Reedy]

Given the following..

#!/usr/bin/python

import urllib2
import sys
import time

while 1:
try:
con = urllib2.urlopen("http://www.google.com")
data = con.read()
print "connected"
#The loop doesn't exit if I use sys.exit(1)

Guess how sys.exit is implemented (or check the fine library manual
chapter on the sys module, .exit entry, 2nd sentence).

break
except:

and guess what this does, and why bare excepts are not recommended
unless you mean what you say...

 

[Von]

Try to use sys.exit(0)
Maybe you should print out the error in your except block.

 

[Steven D'Aprano]

A minor point: this is more explanatory and less misleading if you write
it as ‘while True’.

Why is it misleading? Is there some circumstance in Python where the
literal 1 could have a false value?

"while 1" was the accepted idiom for infinite loops in Python for many
years, before the introduction of bools in (I think) Python 2.2. "while
1" is used used as a micro-optimization in versions of Python below (I
think) 2.7. You might prefer "while True" as nicer or even more Pythonic,
but I disagree that "while 1" is misleading.

 

[Lawrence D'Oliveiro]

Don't ever use a bare ‘except’ unless you know exactly why you're doing
so.

In other news, don’t ever put a loaded gun in your mouth and pull the
trigger unless you know exactly why you’re doing so.

Some people have a problem. They say, “I know, I’ll use an exceptionâ€. Now
they have Some people have a problem. They say, “I know, I’ll use an
exceptionâ€. Now they have ...

 

[Seebs]

In other news, don???t ever put a loaded gun in your mouth and pull the
trigger unless you know exactly why you???re doing so.

I don't think those are at all comparable, I've heard of people who had
plausible arguments for the gun.

-s

 

[Lawrence D'Oliveiro]

I don't think those are at all comparable, I've heard of people who had
plausible arguments for the gun.

 

[Steven D'Aprano]

Try to use sys.exit(0)
Maybe you should print out the error in your except block.

Not exiting with a status-code of 0 is no more helpful than not exiting
with a status-code of 1.

It's actually *less* helpful, if the intention is actually to exit with a
non-zero exit status.

 

[Nobody]

Here's your problem. Don't ever use a bare ‘except’ unless you know
exactly why you're doing so. Rather, figure out what exception types you
want to catch, and catch *only* those types.

If I use a bare except, I usually have a good reason, namely that the
documentation doesn't actually mention which exceptions can be raised.
This is usually because the code doesn't actually know which exceptions
can be raised.

If a module defines:

def foo(f):
f.bar()
...

the set of exceptions which foo() can raise is limitless. The user can
pass whatever they like as "f", and its bar() method can raise anything.

Knowing which exceptions a function or method can raise is the exception
rather than the rule.

If I'm catching exceptions in order to perform clean-up, I'll use a bare
except and re-raise the exception afterwards. In that situation, a bare
except is usually the right thing to do.

If I'm not going to re-raise the exception, I'll either catch Exception or
add explicit catches for SystemExit and KeyboardInterrupt which re-raise
the exception.

 

[Lawrence D'Oliveiro]

If I'm catching exceptions in order to perform clean-up, I'll use a bare
except and re-raise the exception afterwards. In that situation, a bare
except is usually the right thing to do.

Wrong way to do it.

 

[Peter Otten]

Why is it misleading? Is there some circumstance in Python where the
literal 1 could have a false value?

Wrong question.
.... print "forever"
....0

So, if I were to play advocatus diaboli I'd argue that 'while True: ...' is
more likely to mislead because 'True' could be anything.

Peter

PS: The above is no longer possible in Python 3 where True and False have
become keywords.

 

[Ethan Furman]

Wrong way to do it.

What, then, is the right way to do it?

~Ethan~

 

[Nobody]

What, then, is the right way to do it?

I presume that he's referring to "finally". Which is reasonable enough
given what I wrote, but isn't always convenient.

My point was that bare excepts aren't a problem if you're going to
re-raise the exception.

 

[Arnaud Delobelle]

I presume that he's referring to "finally". Which is reasonable enough
given what I wrote, but isn't always convenient.

My point was that bare excepts aren't a problem if you're going to
re-raise the exception.

If I understand correctly, there is a big difference between bare except
and finally:
.... try:
.... if x:
.... raise ValueError("x should be falsy")
.... except:
.... print("bare except")
.... raise
.... finally:
.... print("finally")
.... bare except
finally
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in f
ValueError: x should be falsy

The finally: clause is always executed, whereas the bare except: clause
is only executed if an exception was raised in the try: clause.