[issue25489] sys.exit() caught in exception handler

2022-03-20 Thread Guido van Rossum
Guido van Rossum added the comment: With python built from main I get: /Users/guido/test_sys_exit_in_exception_handler.py:12: DeprecationWarning: There is no current event loop loop = asyncio.get_event_loop() Got error, exiting Exception ignored in: > Traceback (most recent call last):

[issue25489] sys.exit() caught in exception handler

2022-03-20 Thread Guido van Rossum
Guido van Rossum added the comment: Nevertheless, the example code still hangs after calling sys.exit(). I can't quite tell where it is hanging. -- ___ Python tracker ___

[issue25489] sys.exit() caught in exception handler

2022-03-20 Thread Andrew Svetlov
Andrew Svetlov added the comment: The change exists since Python 3.8 (October of 2019) The issue discussion belongs to 2015 -- ___ Python tracker ___

[issue25489] sys.exit() caught in exception handler

2022-03-20 Thread Andrew Svetlov
Andrew Svetlov added the comment: Not sure if the issue is still relevant. asyncio re-raises KeyboardInterrupt explicitly in all loop.call_exception_handler() branches: https://github.com/python/cpython/blob/main/Lib/asyncio/base_events.py#L1759-L1814 --

[issue25489] sys.exit() caught in exception handler

2022-03-20 Thread Guido van Rossum
Guido van Rossum added the comment: Andrew, would you be interested in investigating this? I can't even follow the flow through asyncio that causes the observed behavior (though I seem to have confirmed it). -- nosy: +asvetlov ___ Python tracker

[issue25489] sys.exit() caught in exception handler

2022-03-20 Thread Irit Katriel
Irit Katriel added the comment: See also Issue46759. -- nosy: +iritkatriel ___ Python tracker ___ ___ Python-bugs-list mailing

[issue25489] sys.exit() caught in exception handler

2015-10-30 Thread Brian Sutherland
Brian Sutherland added the comment: On Wed, Oct 28, 2015 at 03:32:36PM +, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > How about we extend loop.stop() so that you can pass it an exception to > raise once the loop is stopped? This exception would then be thrown out of

[issue25489] sys.exit() caught in exception handler

2015-10-30 Thread Guido van Rossum
Guido van Rossum added the comment: OK, I'll wait for someone to submit a patch for this. (I tried a quick hack, but unless we limit this to BaseException instances that aren't also Exception instances it's complicated). -- ___ Python tracker

[issue25489] sys.exit() caught in exception handler

2015-10-29 Thread Brian Sutherland
Brian Sutherland added the comment: On Wed, Oct 28, 2015 at 02:49:55PM +, R. David Murray wrote: > > R. David Murray added the comment: > > Using sys.exit means you are depending on garbage collection to clean > up all of your program's resources. In the general case this is a bad > idea.

[issue25489] sys.exit() caught in exception handler

2015-10-28 Thread R. David Murray
R. David Murray added the comment: Using sys.exit means you are depending on garbage collection to clean up all of your program's resources. In the general case this is a bad idea. A better design is to call loop.stop, and then do cleanup (which might involve calling some wait_closed

[issue25489] sys.exit() caught in exception handler

2015-10-28 Thread Guido van Rossum
Guido van Rossum added the comment: How about we extend loop.stop() so that you can pass it an exception to raise once the loop is stopped? This exception would then be thrown out of run_forever(). There may be some delay (callbacks already scheduled will run first) but it is how things were

[issue25489] sys.exit() caught in exception handler

2015-10-28 Thread Brian Sutherland
Brian Sutherland added the comment: Calling loop.stop() means that I need other, more complex code, to store and return the non-zero exit status. -- ___ Python tracker

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread Brian Sutherland
New submission from Brian Sutherland: Running the attached file with python3 shows that SystemExit is caught rather than causing the process to stop. That's quite surprising. -- components: asyncio files: test_sys_exit_in_exception_handler.py messages: 253529 nosy: gvanrossum, haypo,

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread R. David Murray
R. David Murray added the comment: Ah, I misunderstood your report, because I didn't actually run the example. The exception is being ignored because it is raised during a __del__ method execution. This has nothing to do with set_exception_handler. And in fact if you raise sys.exit in an

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread Yury Selivanov
Yury Selivanov added the comment: > because in that case the handler isn't getting called from the Task __del__ It's possible to fix -- see the attached future.patch. And perhaps this should be fixed in Future.__del__ and Task.__del__ -- ignoring BaseExceptions isn't good. --

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread Brian Sutherland
Brian Sutherland added the comment: the workaround I am using at the moment is this: def handler(loop, context): print('Got error, exiting') loop.call_soon(sys.exit, 42) which actually does cause the process to exit -- ___ Python tracker

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread R. David Murray
R. David Murray added the comment: Not until you convince me there is a reason for deviating from Python's normal __del__ handling :) (Or other asyncio developers agree with you and not me.) -- ___ Python tracker

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread Yury Selivanov
Yury Selivanov added the comment: > No, you are talking about *all* exceptions, since they all descend from > BaseException. Python's normal __del__ handling just prints the ignored > exception to stdout, even if it is a BaseException. Why should asyncio be > different (other than logging

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread R. David Murray
R. David Murray added the comment: So, any exception raised in the exception handler will be re-raised via call_soon. I think the message would be clearer if it said that (that the exception comes from the registered exception handler). But, I'm not sure this is a good idea. Exceptions are

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread Yury Selivanov
Yury Selivanov added the comment: Trapping those exceptions in __del__ isn't good. Another way to address this would be to at least modify call_exception_handler to log when an exception handler raises a BaseException error. -- ___ Python tracker

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread Yury Selivanov
Yury Selivanov added the comment: I see your points, but we're talking about BaseExceptions here -- KeyboardInterrupt, SystemExit etc. Those things usually mean that the program has to crash. -- ___ Python tracker

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread R. David Murray
R. David Murray added the comment: No, you are talking about *all* exceptions, since they all descend from BaseException. Python's normal __del__ handling just prints the ignored exception to stdout, even if it is a BaseException. Why should asyncio be different (other than logging it

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread Guido van Rossum
Guido van Rossum added the comment: Whew. Complex issue! The OP should probably use his workaround or call loop.stop() instead of raising SystemExit. Asyncio in general is rather careless about "true" BaseExceptions (i.e. that aren't also Exceptions), we should decide what we want to do for

[issue25489] sys.exit() caught in exception handler

2015-10-27 Thread R. David Murray
R. David Murray added the comment: I expected this function to be parallel to sys.excepthook, but I see that sys.excepthook does not get called if you call sys.exit() at the python prompt. So I guess I agree with you that it is surprising, although I actually expected the opposite (that