adding a simulation mode

[Dieter Maurer]

andrea crotti wrote at 2012-7-12 14:20 +0100:
>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?

There are ways to quit a program immediately without giving
exception handlers a chance to intervene -- though Python does
not make this easy.

Your code above should not do this. If it does, there is likely a bug.


You told us, that the two alternatives above behaved differently --
I expect 'behaved differently with respect to the printing of "here"'.
If you tell us, which alternative printed "here" and which did not,
we would be able to deduce which of the "Popen" or "copytree"
caused the immediate exit.

"Popen" might contain a call to "os._exit" (one of the ways to immediately
quit) -- though it should only call it in the forked child not in the
calling process. "coyptree" might under exceptional circumstances (extremely
deeply nested structures -- surely not for non-existent source and target)
cause a stack overflow (which, too, can lead to immediate death).


In addition, "Popen" and maybe even "copytree" may call platform
dependent functions. Thus, platform information could be relevant.

Under "*nix", you should be able to get some information from
the exit code of a suddenly quiting process. It tells whether
the process died from a fatal signal (a stack overflow would
result in the fatal SIGSEGV) or whether it existed willingly with
an exit code.

--
Dieter