Author pitrou
Recipients eric.araujo, ezio.melotti, jmoy, orsenthil, pitrou
Date 2012-01-20.17:13:24
SpamBayes Score 6.31242e-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?
History
Date User Action Args
2012-01-20 17:13:25pitrousetrecipients: + pitrou, orsenthil, ezio.melotti, eric.araujo, jmoy
2012-01-20 17:13:24pitroulinkissue13736 messages
2012-01-20 17:13:24pitroucreate