This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Traceback logged when SSL handshake fails
Type: behavior Stage: resolved
Components: asyncio, SSL Versions: Python 3.7
Status: closed Resolution: duplicate
Dependencies: Superseder: Don't log OSError exceptions in asyncio transports
View: 37035
Assigned To: christian.heimes Nosy List: Harmon758, asvetlov, aymeric.augustin, cdods, christian.heimes, hniksic, lilydjwg, yselivanov
Priority: normal Keywords:

Created on 2018-08-26 07:44 by hniksic, last changed 2022-04-11 14:59 by admin. This issue is now closed.

File name Uploaded Description Edit hniksic, 2018-08-26 07:44
Messages (5)
msg324113 - (view) Author: Hrvoje Nikšić (hniksic) * Date: 2018-08-26 07:44
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

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.
msg335547 - (view) Author: cdods (cdods) Date: 2019-02-14 17:50
Any update on this one? Still happening on 3.7.1
msg345760 - (view) Author: Aymeric Augustin (aymeric.augustin) * Date: 2019-06-16 16:30
The same issue was reported in the bug tracker for websockets:
msg345843 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2019-06-17 10:56
I believe the issue is a duplicate for #37035 at least regarding traceback logging.

It can be closed, OSError exceptions are not logged anymore.
msg345844 - (view) Author: Aymeric Augustin (aymeric.augustin) * Date: 2019-06-17 10:58
Yes, that seems reasonable.
Date User Action Args
2022-04-11 14:59:05adminsetgithub: 78687
2019-06-17 11:40:59asvetlovsetstatus: open -> closed
superseder: Don't log OSError exceptions in asyncio transports
resolution: duplicate
stage: resolved
2019-06-17 10:58:17aymeric.augustinsetmessages: + msg345844
2019-06-17 10:56:17asvetlovsetmessages: + msg345843
2019-06-16 18:53:08ned.deilysetnosy: + yselivanov, asvetlov
components: + asyncio
2019-06-16 16:30:48aymeric.augustinsetnosy: + aymeric.augustin
messages: + msg345760
2019-03-22 10:49:16lilydjwgsetnosy: + lilydjwg
2019-03-11 08:59:23Harmon758setnosy: + Harmon758
2019-02-14 17:50:24cdodssetassignee: christian.heimes
type: behavior
components: + SSL
versions: + Python 3.7
nosy: + cdods, christian.heimes

messages: + msg335547
2018-08-26 07:44:30hniksiccreate