New submission from Hrvoje Nikšić <hnik...@gmail.com>: When an SSL handshake fails in asyncio, an exception traceback is logged to standard error even if the application code catches the exception. This logging cannot be suppressed, except by providing a custom exception handler for the whole event loop. The question was raised on StackOverflow in https://stackoverflow.com/q/52012488/1600898
To reproduce the issue, run the attached minimal example (taken from the SO question). Expected behavior is for "Error handled" to be printed. Actual behavior is that, in addition to that line, two tracebacks are printed. It looks like a bug that _fatal_error both logs the exception and calls connection_lost on the protocol (through transport._force_close()). If the idea is for the exception not to get swallowed by protocols that don't implement a sensible connection_lost (e.g. because they've just inherited from BaseProtocol, like the echo server examples), then maybe a protocol that propagates the exception in connection_lost should be able to opt out of the additional logging. That way the stream protocols would avoid spurious output for the suppressed exception by default, and the same opt-out mechanism would be available to user-written protocols. ---------- files: sslerr.py messages: 324113 nosy: hniksic priority: normal severity: normal status: open title: Traceback logged when SSL handshake fails Added file: https://bugs.python.org/file47763/sslerr.py _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34506> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
