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.

Author demian.brecht
Recipients Yuri.Bochkarev, agriffis, alanjds, amak, cananian, demian.brecht, icordasc, jcea, jhylton, martin.panter, mhammond, orsenthil, r.david.murray, rbcollins
Date 2015-02-20.15:34:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> On Feb 19, 2015, at 8:08 PM, Martin Panter <> wrote:
> I guess you saying RemoteDisconnected effectively means the same thing as ConnectionResetError.


> 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.
Date User Action Args
2015-02-20 15:34:57demian.brechtsetrecipients: + demian.brecht, jhylton, mhammond, jcea, orsenthil, amak, rbcollins, cananian, r.david.murray, alanjds, agriffis, martin.panter, icordasc, Yuri.Bochkarev
2015-02-20 15:34:57demian.brechtlinkissue3566 messages
2015-02-20 15:34:57demian.brechtcreate