Message151698
| Author |
pitrou |
| Recipients |
eric.araujo, ezio.melotti, jmoy, orsenthil, pitrou |
| Date |
2012年01月20日.17:13:24 |
| SpamBayes Score |
6.3124156e-07 |
| Marked as misclassified |
No |
| Message-id |
<1327079490.3333.9.camel@localhost.localdomain> |
| In-reply-to |
<1327078858.65.0.535044695004.issue13736@psf.upfronthosting.co.za> |
| Content |
> Antoine, could "raise ... from" be used here?
That's a possible compromise indeed. It's up to Senthil to decide
anyway.
> Perhaps also using new subclasses of URLError to allow the exceptions
> to be caught with finer granularity. That way no information would be
> lost while at the same time not surprising clients who only catch
> URLError based on the documentation.
I agree there is a problem with the documentation announcing that all
exceptions will be wrapped. Honestly I would like it better if that
guarantee were dropped. In the meantime I'm not sure what the best
course of action is.
> At least one exception which I feel must be wrapped is socket.timeout.
> Since we allow a timeout argument to urlopen, it doesn't make sense
> for the fact of the timeout to be announced by an exception from
> another library.
You still may be interested to know that the request failed because of a
timeout rather than (say) an authentication failure, no? |
|