Andrew Svetlov <andrew.svet...@gmail.com> added the comment:
I can describe what happens with test_sys_exit_in_exception_handler.py 1. The 'boom' task raises an exception. 2. The task is not awaited, Future.__del__ calls the exception handler with 'Task exception was never retrieved' message. 3. The custom handler raises SystemExit. 4. SystemExit bubbles up and swallowed by __del__, the __del__ method cannot re-raise. The question is: what is the behavior expected? a) Now an exception raised by a custom exception handler is swallowed in this particular case (but is propagated if `loop.call_exception_handler()` is called from a function other than __del__). b) Yuri suggested re-schedule an exception generated by `loop.call_exception_handler` by `loop.call_soon()`. asyncio.Handle catches it and... calls `call_exception_handler()` with 'Exception in callback ...' message. At the end, we have an endless recursion. c) asyncio loop can call `loop.stop()` if an exception is raised by `loop.call_exception_handler()` from __del__. I think this behavior is terrible: a subtle error can terminate asyncio program. d) Assume that a custom exception handler should not raise an exception. Catch all exceptions in `call_exception_handler`, call sys.unraisablehook(), and suppress the exception. I believe that d) is the best thing that we can do here. I can prepare a fix if we agree on the solution. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25489> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
