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?

Re: adding a simulation mode
 

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"

Re: adding a simulation mode
 

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

Re: adding a simulation mode
 

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"

Re: adding a simulation mode
 

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

Re: adding a simulation mode
 

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

Re: adding a simulation mode
 

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/excep...tion-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

Re: adding a simulation mode
 

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

Re: adding a simulation mode
 

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

Re: adding a simulation mode
 

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/excep...tion-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