Re: adding a simulation mode

Discussion in 'Python' started by andrea crotti, Jul 12, 2012.

  1. One thing that I don't quite understand is why some calls even if I
    catch the exception still makes the whole program quit.
    For example this

    try:
    copytree('sjkdf', 'dsflkj')
    Popen(['notfouhd'], shell=True)
    except Exception as e:
    print("here")


    behaves differently from:

    try:
    Popen(['notfouhd'], shell=True)
    copytree('sjkdf', 'dsflkj')
    except Exception as e:
    print("here")

    because if copytree fails it quits anyway.
    I also looked at the code but can't quite get why.. any idea?
     
    andrea crotti, Jul 12, 2012
    #1
    1. Advertising

  2. andrea crotti

    John Gordon Guest

    In <> andrea crotti <> writes:

    > try:
    > copytree('sjkdf', 'dsflkj')
    > Popen(['notfouhd'], shell=True)
    > except Exception as e:
    > print("here")


    > behaves differently from:


    > try:
    > Popen(['notfouhd'], shell=True)
    > copytree('sjkdf', 'dsflkj')
    > except Exception as e:
    > print("here")


    > because if copytree fails it quits anyway.
    > I also looked at the code but can't quite get why.. any idea?


    copytree() could contain a call to sys.exit(), although that seems like
    a rude thing to do.

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, Jul 12, 2012
    #2
    1. Advertising

  3. Well that's what I thought, but I can't find any explicit exit
    anywhere in shutil, so what's going on there?
     
    andrea crotti, Jul 12, 2012
    #3
  4. andrea crotti

    John Gordon Guest

    In <> andrea crotti <> writes:

    > Well that's what I thought, but I can't find any explicit exit
    > anywhere in shutil, so what's going on there?


    Try catching SystemExit specifically (it doesn't inherit from Exception,
    so "except Exception" won't catch it.)

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, Jul 12, 2012
    #4
  5. 2012/7/12 John Gordon <>:
    > In <> andrea crotti <> writes:
    >
    >> Well that's what I thought, but I can't find any explicit exit
    >> anywhere in shutil, so what's going on there?

    >
    > Try catching SystemExit specifically (it doesn't inherit from Exception,
    > so "except Exception" won't catch it.)
    >
    > --


    Ah yes that actually works, but I think is quite dodgy, why was it
    done like this?
    In shutil there is still no mention of SystemExit, and trying to raise
    the single exceptions by and
    doens't still make it exit, so I would still like to know how it is
    possible just for curiosity..
     
    andrea crotti, Jul 12, 2012
    #5
  6. On Thu, 12 Jul 2012 15:17:03 +0100, andrea crotti wrote:

    > Well that's what I thought, but I can't find any explicit exit anywhere
    > in shutil, so what's going on there?


    Hard to say, since you don't give any context to your question.

    When replying to posts, please leave enough quoted to establish context.
    Neither email nor usenet are guaranteed delivery services, and they
    certainly don't guarantee to deliver messages in order. Assume that your
    readers may not have seen the message you are replying to, and you will
    probably get more and better responses.



    --
    Steven
     
    Steven D'Aprano, Jul 13, 2012
    #6
  7. On Thu, 12 Jul 2012 16:37:42 +0100, andrea crotti wrote:

    > 2012/7/12 John Gordon <>:
    >> In <> andrea crotti
    >> <> writes:
    >>
    >>> Well that's what I thought, but I can't find any explicit exit
    >>> anywhere in shutil, so what's going on there?

    >>
    >> Try catching SystemExit specifically (it doesn't inherit from
    >> Exception, so "except Exception" won't catch it.)
    >>

    >
    > Ah yes that actually works, but I think is quite dodgy, why was it done
    > like this?


    Built-in exceptions SystemExit, KeyboardInterrupt and GeneratorExit
    deliberately do not inherit from Exception since they are not meant to be
    caught by "catch-all" try...except Exception clauses.

    You can see the exception hierarchy here:

    http://docs.python.org/library/exceptions.html#exception-hierarchy

    Please do NOT catch BaseException, since that is the wrong thing to do.
    If you must catch SystemExit, KeyboardInterrupt, etc. they you should do
    so as separate catch clauses:

    try:
    main()
    except SystemExit as e:
    print(e) # see if we can find out who is raising this
    except KeyboardInterrupt:
    print("Mwahahaha my pretty, you cannot cancel this!!!")
    print("...er, now what do I do?")
    except Exception:
    print("why am I catching exceptions I can't recover from?")


    --
    Steven
     
    Steven D'Aprano, Jul 13, 2012
    #7
  8. On Thu, 12 Jul 2012 14:20:18 +0100, andrea crotti wrote:

    > One thing that I don't quite understand is why some calls even if I
    > catch the exception still makes the whole program quit.


    Without seeing your whole program, we can't possibly answer this. But by
    consulting my crystal ball, I bet you have something like this:

    try:
    do_stuff() # run your program
    except Exception as e:
    # pointlessly catch exceptions I can't handle, which has the
    # bonus of making debugging MUCH MUCH harder
    print("here")
    # end of file, nothing further to do


    When do_stuff() fails, "here" gets printed, and then the program exits
    because there's nothing else to do.

    Catching exceptions doesn't magically cause the code to continue from the
    point of the error. It doesn't work like that. Execution skips from where
    the error occurred to the except clause. Once the except clause has run,
    anything following the except clause runs, and then the program ends as
    normal.

    If you haven't already done so, I recommend you go through the tutorial:

    http://docs.python.org/py3k/tutorial/index.html

    in particular the part about exception handling:

    http://docs.python.org/py3k/tutorial/errors.html


    > For example this
    >
    > try:
    > copytree('sjkdf', 'dsflkj')
    > Popen(['notfouhd'], shell=True)
    > except Exception as e:
    > print("here")


    What is "Popen" and where is it from?

    My first guess was os.popen, but that doesn't take a shell argument:

    py> os.popen(['ls', '-l'], shell=True)
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: popen() got an unexpected keyword argument 'shell'


    > behaves differently from:
    >
    > try:
    > Popen(['notfouhd'], shell=True)
    > copytree('sjkdf', 'dsflkj')
    > except Exception as e:
    > print("here")
    >
    > because if copytree fails it quits anyway.



    Well of course it does. If copytree fails, the try block ends and
    execution skips straight to the except block, which runs, and then the
    program halts because there's nothing else to be done.

    That at least is my guess, based on the described symptoms.




    --
    Steven
     
    Steven D'Aprano, Jul 13, 2012
    #8
  9. 2012/7/13 Steven D'Aprano <>:

    > Well of course it does. If copytree fails, the try block ends and
    > execution skips straight to the except block, which runs, and then the
    > program halts because there's nothing else to be done.
    >
    > That at least is my guess, based on the described symptoms.
    >


    Well I think that's what I was stupidly missing, I always had only one
    possibly failing thing in a try/except block,
    and I always gave for granted that it doesn't jump to the except block
    on first error, but of course it makes
    more sense if it does...

    Thanks a lot
     
    andrea crotti, Jul 13, 2012
    #9
  10. andrea crotti

    Hans Mulder Guest

    On 13/07/12 04:16:53, Steven D'Aprano wrote:
    > On Thu, 12 Jul 2012 16:37:42 +0100, andrea crotti wrote:
    >
    >> 2012/7/12 John Gordon <>:
    >>> In <> andrea crotti
    >>> <> writes:
    >>>
    >>>> Well that's what I thought, but I can't find any explicit exit
    >>>> anywhere in shutil, so what's going on there?
    >>>
    >>> Try catching SystemExit specifically (it doesn't inherit from
    >>> Exception, so "except Exception" won't catch it.)
    >>>

    >>
    >> Ah yes that actually works, but I think is quite dodgy, why was it done
    >> like this?


    It may be that the function you're calling found a problem that the
    author thinks is so grave that they shouldn't give you an opportunity
    to deal with it.

    If that's the case, I would be inclined to think that they are wrong.

    > Built-in exceptions SystemExit, KeyboardInterrupt and GeneratorExit
    > deliberately do not inherit from Exception since they are not meant to be
    > caught by "catch-all" try...except Exception clauses.
    >
    > You can see the exception hierarchy here:
    >
    > http://docs.python.org/library/exceptions.html#exception-hierarchy
    >
    > Please do NOT catch BaseException, since that is the wrong thing to do.


    I would agree if you had said "in production code".

    If you are investigating why a third-party function is stopping your
    interpreter, then catching BaseException may tell you that the code
    is raising the wrong kind of Exception. Once you know what kind the
    function is raising, you should catch only that particular excpetion
    subclass.


    > If you must catch SystemExit, KeyboardInterrupt, etc. they you should do
    > so as separate catch clauses:
    >
    > try:
    > main()
    > except SystemExit as e:
    > print(e) # see if we can find out who is raising this


    If you want to find out who is raising the exception, you could
    try this:

    except SystemExit:
    import traceback
    traceback.print_exc()

    That will print a complete stack trace.

    If you only need to know what kind of exception you have,
    you can do:

    print(repr(e))

    A simple print(e) will print str(e), which in the case of
    SystemExit, is an empty string. That's not very informative.

    > except KeyboardInterrupt:
    > print("Mwahahaha my pretty, you cannot cancel this!!!")
    > print("...er, now what do I do?")
    > except Exception:
    > print("why am I catching exceptions I can't recover from?")



    Hope this helps,

    -- HansM
     
    Hans Mulder, Jul 13, 2012
    #10
  11. > > Please do NOT catch BaseException, since that is the wrong thing to do.

    >
    > I would agree if you had said "in production code".
    >
    > If you are investigating why a third-party function is stopping your
    > interpreter, then catching BaseException may tell you that the code
    > is raising the wrong kind of Exception. Once you know whatkind the
    > function is raising, you should catch only that particularexcpetion
    > subclass.


    I would say the opposite. In production code usually I want it
    to recover, log as much information as I need (including sending
    any notifications), and NOT just die.

    In development, not catching the exception will give me a full
    trace back automatically. Why bother with trying to catch and
    print something when the interpreter will do it for me? Not
    to mention that removes any hassle of trying to catch the
    "right" exception or figuring out the best way to print it.
    I suppose if there are argumentson the exception that were not
    printed then I might want to catch it,but has been rare
    in my experience.

    Ramit

    This email is confidential and subject to important disclaimers and
    conditions including on offers for the purchase or sale of
    securities, accuracy and completeness of information, viruses,
    confidentiality, legal privilege, and legal entity disclaimers,
    available at http://www.jpmorgan.com/pages/disclosures/email.
     
    Prasad, Ramit, Jul 13, 2012
    #11
  12. On Sat, Jul 14, 2012 at 3:08 AM, Prasad, Ramit
    <> wrote:
    > I would say the opposite. In production code usually I want it
    > to recover, log as much information as I need (including sending
    > any notifications), and NOT just die.
    >
    > In development, not catching the exception will give me a full
    > trace back automatically.


    Here's another take on the matter. In development, your script is your
    execution unit, so you let the interpreter print out your tracebacks.
    In production, there will usually be one, maybe two subunits (for
    instance, a TCP-based server might have the socket connection as an
    execution unit, and possibly a command parser inside that), and at the
    top of that subunit, you have a broad exception handler that resets
    that one unit (goes back and accepts another client, or waits for
    another command). Otherwise, wide-scope exception handling is usually
    a bad thing.

    ChrisA
     
    Chris Angelico, Jul 13, 2012
    #12
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. andrea crotti

    adding a simulation mode

    andrea crotti, Jul 4, 2012, in forum: Python
    Replies:
    4
    Views:
    222
    Paul Rubin
    Jul 4, 2012
  2. Mike C. Fletcher

    Re: adding a simulation mode

    Mike C. Fletcher, Jul 4, 2012, in forum: Python
    Replies:
    0
    Views:
    177
    Mike C. Fletcher
    Jul 4, 2012
  3. Devin Jeanpierre

    Re: adding a simulation mode

    Devin Jeanpierre, Jul 4, 2012, in forum: Python
    Replies:
    0
    Views:
    196
    Devin Jeanpierre
    Jul 4, 2012
  4. Dieter Maurer

    Re: adding a simulation mode

    Dieter Maurer, Jul 5, 2012, in forum: Python
    Replies:
    0
    Views:
    177
    Dieter Maurer
    Jul 5, 2012
  5. andrea crotti

    Re: adding a simulation mode

    andrea crotti, Jul 5, 2012, in forum: Python
    Replies:
    0
    Views:
    169
    andrea crotti
    Jul 5, 2012
Loading...

Share This Page