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.

Any update on this one? Still happening on 3.7.1

The same issue was reported in the bug tracker for websockets: https://github.com/aaugustin/websockets/issues/614

I believe the issue is a duplicate for #37035 at least regarding traceback logging.

It can be closed, OSError exceptions are not logged anymore.

Yes, that seems reasonable.