gh-122909: Pass ftp error strings to URLError constructor #122913
Conversation
|
The change here is debatable. The docs says that URLError() can be passed a string or an object, and the implementation actually allows two arguments (where the second is stored as filename). According to those docs, the original code is correct and we should actually change test/support/sockethelper to check the type of the URLError reason. However, the urllib code for ftp support mostly passes strings to URLError instead of ftplib.Error instances. This change would make the code more consistent, at the risk of breaking some client code that depended on exactly the implementation of error handling for ftp. |
|
The consistency is good, but we should mention this minor behavior in a NEWS entry. |
|
FWIW - I agree that this change makes sense. However long the current behavior has existed, it strikes me as incorrect. |
|
All commit authors signed the Contributor License Agreement. |
Change error string for ftp error to be consistent with other errors reported for ftp
…on#122913) * pass the original string error message from the ftplib error to URLError() * Update request.py Change error string for ftp error to be consistent with other errors reported for ftp * Add NEWS entry for change to urllib.request for ftp errors. * Track the change in the ftp error message in the test.
ftplib exceptions are very simple. They inherit from Exception and define no additional behavior. The modules raises exceptions that just take a single string argument.
The URLError exception constructor takes a string that description the error.
Fix the handler for ftp errors to pass the original error string to URLError() instead of the ftplib.Error() instance.