[issue18836] Potential race condition in exceptions

Sworddragon added the comment: > You may want to have a look at sys.excepthook. This would not solve the race condition. -- ___ Python tracker ___ __

[issue18836] Potential race condition in exceptions

Charles-François Natali added the comment: > If it is intended not to be able to catch all exceptions > and prevent a traceback being showed this should be indeed a PEP. You may want to have a look at sys.excepthook. -- nosy: +neologix ___ Python tra

[issue18836] Potential race condition in exceptions

Sworddragon added the comment: > Unless I'm completely misunderstanding (which I don't think I am), this is > not a race condition, it is how the language is designed to operate. If it is intended not to be able to catch all exceptions and prevent a traceback being showed this should be indeed

[issue18836] Potential race condition in exceptions

R. David Murray added the comment: Unless I'm completely misunderstanding (which I don't think I am), this is not a race condition, it is how the language is designed to operate. The change you are proposing is a language-design level change that would require a PEP. The appropriate place to

[issue18836] Potential race condition in exceptions

Sworddragon added the comment: > but what if there is a bug in your code? Bugs in a python application can be fixed by the user while a specific behavior of the interpreter can't. Maybe you are also thinking in the wrong direction. Nobody wants a solution that traps the user forever. Also Key

[issue18836] Potential race condition in exceptions

R. David Murray added the comment: I wonder if you could achieve what you want (which I always hope programs I use never do[*]) by writing your own signal handler. In any case, I don't believe there is a bug here. This is working as designed. [*] There are many times I have found myself leani

[issue18836] Potential race condition in exceptions

Sworddragon added the comment: The problem is simple: It is not possible to catch every exception in an application. Even if you try to print a message and exit on an exception it is always possible that the user will see a traceback. -- ___ Python

[issue18836] Potential race condition in exceptions

R. David Murray added the comment: Then you catch KeyboardInterrupt and present your alternate text. I'm not following what the problem is. In particular, once you've caught KeyboardInterrupt, a second ctl-C *should* cause a normal program break, otherwise you've locked the user into a infini

[issue18836] Potential race condition in exceptions

Sworddragon added the comment: > Are you saying that if the user keeps hitting ctrl+c you would need an > endless chain of nested try/except in order to catch them all? Correct. For example if I want to show the user the message "Aborted" instead of a huge exception if he hits CTRL + C another

[issue18836] Potential race condition in exceptions

Ezio Melotti added the comment: > The third CTRL + C will cause a KeyboardInterrupt. This is expected. The first ctrl+c interrupts the first sleep and goes in the second try, executing the second sleep. The second ctrl+c interrupts the second sleep and goes in the second except where it find

[issue18836] Potential race condition in exceptions

Changes by Sworddragon : Added file: http://bugs.python.org/file31470/race_condition_slow.py ___ Python tracker ___ ___ Python-bugs-list maili

[issue18836] Potential race condition in exceptions

New submission from Sworddragon: On a try/except-block if an exception raises (for example KeyboardInterrupt) the except block could cause another exception and if this block tries to catch it too the nested except block could cause another exception again. This goes into an unlimited recursio