R. David Murray added the comment: This is a general principle in Python. A module may raise specific errors, but there are always other errors that may be raised. The wording could be clarified, but it should not be removed. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22797> _______________________________________

R. David Murray added the comment: (Looking at your new patch...thanks for giving it a try even though I wasn't clear). There are lots of other errors it can raise, too. I was thinking more along the lines of "raises URLError on http protocol errors". The problem is that's not completely accurate, either, but I don't remember exactly when it is that HTTPError can leak through. Just for reference, in my code that calls urlopen and needs to keep running it if can't access the URL no matter what the (network-derived) reason, I catch ConnectionError, HTTPError, URLError, and IncompleteRead. We do not document all possible exceptions. We document those that are specific to the module in question (which is URLError in this case) or that are part of the documented API (such as mentioning TimeoutError as what happens if the timeout specified by a timeout keyword is exceeded). ValueErrors are a general class of errors that, when encountered, usually mean you need to fix your code (or, in the case of the SSL one you mention, check for SSL support at startup, assuming I understood correctly), rather than something you would catch around the urlopen call in a typical program. There are, of course, occasions when you *do* catch ValueErrors in specific bits of code, but there is no practical way we can document all of the reasons ValueError might get raised, so we don't try. All of that said, it would be lovely to have a reference somewhere (maybe a tutorial?) that went over all the possible exceptions one might get while using various network libraries, and why they might arise. It is an issue that comes from the fact that the libraries are built on top of each other and the general python technique is that lower level errors are allowed to bubble up. It would be a beast to keep up to date, though, which is probably one reason we don't have one. But even that kind of guide wouldn't include ValueErrors. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22797> _______________________________________

Roundup Robot added the comment: New changeset aed4b9981fca by R David Murray in branch '3.5': #22797: clarify when URLErrors are raised by urlopen. https://hg.python.org/cpython/rev/aed4b9981fca New changeset d085b4f779af by R David Murray in branch '3.5': Merge: #22797: clarify when URLErrors are raised by urlopen. https://hg.python.org/cpython/rev/d085b4f779af ---------- nosy: +python-dev _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22797> _______________________________________

Roundup Robot added the comment: New changeset b4df20312b78 by R David Murray in branch 'default': Clean up urlopen doc string. https://hg.python.org/cpython/rev/b4df20312b78 ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22797> _______________________________________

Roundup Robot added the comment: New changeset 2d69d0419879 by Martin Panter in branch 'default': Issue #22797: Synchronize urlopen() doc string with RST documentation https://hg.python.org/cpython/rev/2d69d0419879 ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue22797> _______________________________________