[Patches] httplib.HTTP.connect raises wrong exception

[Guido van Rossum]

>     Skip> In httplib.HTTP.connect a socket.error is raised when a
>     Skip> non-numeric port is given.  Seems to me this is more correctly a
>     Skip> ValueError.
> 
>     Guido> Hmm...  It explicitly catches the ValueError and raises
>     Guido> socket.error.  Why could it be doing this?  (Also, it does the
>     Guido> same thing elsewhere in the module.)

[Skip]
> Not sure.  The more I see of one module raising other modules' errors, the
> more I don't like it since it forces the programmer to be aware of
> implementation details of the module being called.
> 
> When a module catches an exception I see three valid options:
> 
>     1. Recover and continue executing
> 
>     2. Embellish the value of the exception (perhaps adding a concrete
>        filename or other value), then reraise the same exception.
> 
>     3. Raise a new exception defined in this module.  
> 
> Both #2 & #3 should invoke raise with the original stack info so as not to
> confuse programmers trying to debug their mistakes.

I'm wondering, what mistake were you debugging?  There must be an
actual anecdote associated with your patch.

Not necessarily.  Looking at the code it is actually catching
ValueError and raising socket.error.  It appears that it wants to be
helpful by *hiding* the details of the exception: all that matters is
that the port is not numeric.  That this was caught by string.atoi()
is not relevant.  The assumption is also that all errors caused by a
bad "host:port" error will raise socket.error, whether the host lookup
fails or the port is invalid or whatever.  (An unsupported port number
is just as much a "value" error, but it raises a socket error:
Connection refused.)

I would support adding the actual value of the port string to the
error message.  I don't support raising ValueError.

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