Demian Brecht added the comment: > On Feb 19, 2015, at 8:08 PM, Martin Panter <rep...@bugs.python.org> wrote: > I guess you saying RemoteDisconnected effectively means the same thing as > ConnectionResetError.
Exactly. > Would it help if it was derived from ConnectionResetError, instead of the > ConnectionError base class? Or are you also worried about the multiple > inheritance or clutter of yet another type of exception? My concern is more about consistency of exceptions and exception handling when using the client. Thinking about it from a user’s standpoint, when I issue a request and the remote socket closes, I would hope to get consistent exceptions for all remote resets. If I’m handling the lowest level errors independently of one another rather than catch-all ConnectionError, I don’t want to do something like this: except (RemoteDisconnected, ConnectionResetError) I /should/ be able to simply use ConnectionResetError. Reading the docs, the only real reason for this exception at all is for backwards compatibility. If we have a case to break backwards compatibility here, then that eliminates the need for the new exception and potential (minor) confusion. In this special case, the behaviour that we see at the client socket level indicates a remote reset, but it’s only artificially known immediately due to the empty read. In my mind, because the client /knows/ that this is an early indicator of a ConnectionResetError, that is exactly the exception that should be used. Hope that makes sense. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3566> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
