(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.