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

Discussion in 'Python' started by chad, Oct 5, 2010.

  1. chad

    chad Guest

    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.
     
    chad, Oct 5, 2010
    #1
    1. Advertisements

  2. your bare except is catching the SystemExit raised by sys.exit(1)
     
    Justin Ezequiel, Oct 5, 2010
    #2
    1. Advertisements

  3. chad

    Terry Reedy Guest

    Guess how sys.exit is implemented (or check the fine library manual
    chapter on the sys module, .exit entry, 2nd sentence).
    and guess what this does, and why bare excepts are not recommended
    unless you mean what you say...
     
    Terry Reedy, Oct 5, 2010
    #3
  4. chad

    Von Guest

    Try to use sys.exit(0)
    Maybe you should print out the error in your except block.
     
    Von, Oct 5, 2010
    #4
  5. 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.
     
    Steven D'Aprano, Oct 5, 2010
    #5
  6. 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 ...
     
    Lawrence D'Oliveiro, Oct 5, 2010
    #6
  7. chad

    Seebs Guest

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

    -s
     
    Seebs, Oct 5, 2010
    #7
  8. :)
     
    Lawrence D'Oliveiro, Oct 5, 2010
    #8
  9. 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.
     
    Steven D'Aprano, Oct 5, 2010
    #9
  10. chad

    Nobody Guest

    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.
     
    Nobody, Oct 5, 2010
    #10
  11. Wrong way to do it.
     
    Lawrence D'Oliveiro, Oct 11, 2010
    #11
  12. chad

    Peter Otten Guest

    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.
     
    Peter Otten, Oct 11, 2010
    #12
  13. chad

    Ethan Furman Guest

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

    ~Ethan~
     
    Ethan Furman, Oct 11, 2010
    #13
  14. chad

    Nobody Guest

    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.
     
    Nobody, Oct 12, 2010
    #14
  15. 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.
     
    Arnaud Delobelle, Oct 13, 2010
    #15
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.