[Patches] httplib.HTTP.connect raises wrong exception

[Guido van Rossum]

[Skip]
>   >> As a compromise, I propose the following change near the top of
>   >> httplib somewhere after socket has been imported:
>   >> 
>   >> error = socket.error
>   >> 
>   >> Then anywhere httplib raises an error, that should be what it
>   >> raises.  No code that currently catches socket.error will break,
>   >> and httplib.error can be the documented exception used for
>   >> transmitting errors out of that module.
> 
>   GvR> And all this because you believe that raising some other
>   GvR> module's error is a sin?  I don't have a problem with such
>   GvR> behavior -- what's the reason?

[Jeremy]
> I'm not completely opposed to one module raising an exception defined
> in another, although I think I share some of Skip's worries.
> 
> First, the documentation ought to describe the exceptions that can be
> raised.  Documenting the intended exceptions is nearly as important as
> documenting the return value.  It serves the dual purpose of
> describing the contract between caller and callee and helping the
> programmer figure out when the bug is in the library and when the bug
> is in her code.  If you call a function that raises an undocument
> ValueError, then there's a good chance there is a bug in the code.
> 
> Second, there are cases where module A raising B.error seems wrong.
> In the case of httplib, the HTTP object is an abstraction that hides
> the details of mucking with sockets to talk HTTP.  The socket error
> exception exposes the representation of the HTTP object, and forces
> the programmer to import socket & httplib in order to write robust
> httplib code.  Skip's suggestion to httplib.error == socket.error
> helps in that regard.
> 
> +0
> 
> Jeremy

If it's a documentation issue, so fix the documentation.

Although it is apparently not obvious, the HTTP class raises
socket.error for lots of reasons -- invalid arguments being only a
subclass.  This is in its nature, because all it does is make socket
calls to implement the HTTP protocol.

For this reason the one argument validity check that is done
explicitly in the HTTP code is also made to raise socket.error.

Adding httplib.error = socket.error seems like splitting hairs, and
seems to suggest a future migration path that I don't like (it
suggests that in the future httplib.error might *not* be socket.error,
and that it's wrong to catch socket.error when using httplib).

--Guido van Rossum (home page: http://www.python.org/~guido/)