Ivan Pozdeev added the comment: One more concern about the fix (so that you don't assume I didn't think of this ;) ) - handling of errors signified by the end-of-transfer response.
Handling a response in a close handler prevents us from actually checking its code: * destructors like a close handler cannot raise exceptions because that would disrupt the resource release process * and they're routinely called from `finally', so an exception would mask the current one if there's any (it's impossible to check within a finally block if it was was called as a result of an exception - http://stackoverflow.com/questions/1611561/can-i-get-the-exception-from-the-finally-block-in-python). Now, * The errors where the transfer never starts are detected by `ntransfercmd' either when opening the socket (425) or checking the first response (55x) * an exception when opening the socket would result in the response not being read. * The errors when the transfer ends prematurely * are either handled by the socket (connection reset/timeout) * or can be detected by checking data length against the real one if it's available <- these are not currently handled * if it results from the user closing the socket prematurely (426), it _should_ be ignored * otherwise, we can wrap recv(), too, and check the response if the underlying fn returns '' * If the error is local (an exception is raised in other code), the server's response doesn't matter Looks like fixing this part warrants a separate ticket, though it does affect which option to take at this step - it speaks in favor of wrapping the data socket. I'll ask at python-dev for some feedback before I go any way. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25458> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
