See bug 1591774. The base problem is that when passing a file:// url into urllib2.urlopen() for a file that doesn't exist, the os.stat() call fails with an OSError exception which is not caught. The documentation for urllib2 states that urlopen() raises a URLError upon error. This bug can also be triggered when fetching a http:// url. A misconfigured webserver can cause urllib2.urlopen to use the FileHandler (see bug report). This patch catches OSError in the FileHandler class and raises it as a URLError. Unit test included.
I recall that when I wrote the urllib2 tests there were a fair few cases similar to this -- indeed, this particular one is already marked in the tests with an "XXXX" in test_file(). What do other people think about these -- should they be fixed, or the docs changed?
Sorry, I looked at that commented out section and didn't immediately see what it was for, so ignored it. I'm not sure what the correct behavior would be in this case. Getting a OSError from a http:// url is unsettling. I guess that if I were using the library, I would only want to have to catch one type of exception. Having to catch both URLError and OSError is inconvenient. If I were looking for a file on disk I would use file(), so the only time someone probably uses the file:// url syntax is when the end user is entering the URL. The end user wouldn't distinguish between the two exception types in this case.
