That's fine, but you need to look at each case individually, and not try to deal with them as if they were all the same.  This is because you want the correct error to percolate up.  For example, in smtplib we have a case where the server may respond to a command by closing the connection (which is technically a violation of the RFC).  It used to be that smtplib would raise a connection error at that point because it would try to send an RST command to the server over the closed connection.  The original error message reported by the server was lost.  The solution was to rewrite the error handling so that we had an internal send_RST that was different from the one that would be used by the application, and that internal RST send was wrapped in a try/except ignoring the connection error.   That way the command the application called returned the received response, and then the application got the connection closed error the *next* time it tried to use the connection.

nntplib presumably requires as a similar strategy if the network connection terminates unexpectedly: just ignoring the connection closed error when the quit is sent.  The code already closes the connection after the QUIT attempt, so that should leave things in the correct state for all other errors.

Other network errors may benefit from additional handling, but I don't know since I don't have examples here to think about :)

As for the keyboard interrupt problem, it looks like what needs to happen is a custom response handler for the internal QUIT, that will recognize when it is not getting "its" response back and just return.

This is more similar to the smptlib problem than I originally thought: it seems like the basic problem is that that internal QUIT needs custom handling that is different from the QUIT issued at the application level.