Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #25215 > unrolled thread

Re: adding a simulation mode

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: adding a simulation mode andrea crotti <andrea.crotti.0@gmail.com> - 2012-07-12 14:20 +0100
    Re: adding a simulation mode John Gordon <gordon@panix.com> - 2012-07-12 13:56 +0000
      Re: adding a simulation mode andrea crotti <andrea.crotti.0@gmail.com> - 2012-07-12 15:17 +0100
        Re: adding a simulation mode John Gordon <gordon@panix.com> - 2012-07-12 15:10 +0000
          Re: adding a simulation mode andrea crotti <andrea.crotti.0@gmail.com> - 2012-07-12 16:37 +0100
            Re: adding a simulation mode Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-13 02:16 +0000
              Re: adding a simulation mode Hans Mulder <hansmu@xs4all.nl> - 2012-07-13 18:33 +0200
                RE: adding a simulation mode "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-07-13 17:08 +0000
                Re: adding a simulation mode Chris Angelico <rosuav@gmail.com> - 2012-07-14 03:24 +1000
        Re: adding a simulation mode Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-13 02:09 +0000
    Re: adding a simulation mode Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-13 02:37 +0000
      Re: adding a simulation mode andrea crotti <andrea.crotti.0@gmail.com> - 2012-07-13 09:54 +0100

#25215 — Re: adding a simulation mode

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?

[toc] | [next] | [standalone]

#25218

In <mailman.2039.1342099220.4697.python-list@python.org> andrea crotti <andrea.crotti.0@gmail.com> 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
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#25220

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

[toc] | [prev] | [next] | [standalone]

#25221

In <mailman.2043.1342102625.4697.python-list@python.org> andrea crotti <andrea.crotti.0@gmail.com> 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
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#25222

2012/7/12 John Gordon <gordon@panix.com>:
> In <mailman.2043.1342102625.4697.python-list@python.org> andrea crotti <andrea.crotti.0@gmail.com> 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..

[toc] | [prev] | [next] | [standalone]

#25238

On Thu, 12 Jul 2012 16:37:42 +0100, andrea crotti wrote:

> 2012/7/12 John Gordon <gordon@panix.com>:
>> In <mailman.2043.1342102625.4697.python-list@python.org> andrea crotti
>> <andrea.crotti.0@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#25271

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 <gordon@panix.com>:
>>> In <mailman.2043.1342102625.4697.python-list@python.org> andrea crotti
>>> <andrea.crotti.0@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#25273

> > 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.

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 arguments on 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.  

[toc] | [prev] | [next] | [standalone]

#25275

On Sat, Jul 14, 2012 at 3:08 AM, Prasad, Ramit
<ramit.prasad@jpmorgan.com> 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

[toc] | [prev] | [next] | [standalone]

#25236

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

[toc] | [prev] | [next] | [standalone]

#25240

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

[toc] | [prev] | [next] | [standalone]

#25254

2012/7/13 Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web