| msg13871 - (view) |
Author: Thomas Viehmann (t-v) |
Date: 2003-01-04 12:00 |
| Hi. Thanks for urllib2. Urllib2 would be even better if Exceptions were more unified, i.e. if there was way to test any URLException for common failure causes, regardless of the protocol. Example: 'File not found' can happen with http/ftp/gopher/... Cheers Thomas |
|
|
| msg13872 - (view) |
Author: Neal Norwitz (nnorwitz) *  |
Date: 2003-01-05 00:32 |
| Logged In: YES user_id=33168 Perhaps I'm missing something, but I don't understand what you want. All the exceptions in urllib2 derive from URLError, which itself derives from IOError. There are a few cases where IOError is raised. All other cases raise URLError, HTTPError, or GopherError. Isn't IOError (or possibly URLError) what you are looking for? So you would do: try: # your code here except IOError: # handle any urllib2 exception |
|
|
| msg13873 - (view) |
Author: Thomas Viehmann (t-v) |
Date: 2003-01-05 11:16 |
| Logged In: YES user_id=680463 Maybe I was unclear (and maybe it's possible already to do what I want but I'm just to blind to see it). So here is what I want: Attempt one: I'd something like a HTTP status code returned for all protocols, with the library making up the appropriate ones as necessary, if there is none. (So that I can test a gopher-URLError for "e.code==404" Attempt two: When trying to retrieve an URL, I'd like to have a method to detect "Not found", so I would like the following code fragment, which (modulo mistakes introduced in copying this from my code) works with http, to work with gopher (someday ftp or rsync?) as well. try: f = urllib2.open(anurl) except urllib2.URLError,e: if e.code == 404: print "Not found" ... # e.g. try alternative location else: print "Something more serious...." raise e Does this make it more clear? Similar to urllib/urllib2 providing common method to retrieve data for multiple protocols, there should be way to be able to identify errors that are not protocol-specific. (And the letter I did not find.) Thanks Thomas |
|
|
| msg13874 - (view) |
Author: Thomas Viehmann (t-v) |
Date: 2003-01-05 11:18 |
| Logged In: YES user_id=680463 It should be the latter, not the letter, in the previous followup. |
|
|
| msg13875 - (view) |
Author: Jeremy Hylton (jhylton)  |
Date: 2003-02-03 19:50 |
| Logged In: YES user_id=31392 Thomas, This sounds like a nice feature but it doesn't really feel like a bug. I'm also unsure about how many error cases in other protocols map naturally to HTTP error numbers. Feel free to submit a patch if you find that this really works for any signficant number of cases. |
|
|
| msg13876 - (view) |
Author: Thomas Viehmann (t-v) |
Date: 2003-02-03 20:56 |
| Logged In: YES user_id=680463 Sorry, I thought of "wishlist bug". (And believe there should be such a thing.) What would be a chance of a technically sound patch, let's say one that maps ftp-Errors correctly to start with, to be accepted? I should think that rather a lot of protocols should map rather good, though the error reporting might not be as granular as with http. Anything from not found to access denied to timeout is covered. (The mapping doesn't have to be surjective.) In particular, since this would be just an addition, it would certainly not hurt. |
|
|