[Python-Dev] Adding NetworkIOError for bug 1706815

[Gregory P. Smith]

On Thu, Jul 05, 2007 at 12:05:01PM +0200, Guido van Rossum wrote:
> On 7/5/07, Gregory P. Smith <greg at electricrain.com> wrote:
> >On Wed, Jul 04, 2007 at 11:03:42AM +0200, Guido van Rossum wrote:
> >> Why not simply inherit socket.error from EnvironmentError?
> >
> >True, that would be simpler; is it enough?  If we avoid adding the new
> >exception, I really think it should inherit from IOError, not
> >EnviromnentError because sockets are I/O.  urllib2.URLError was
> >already a child of IOError; doing the same to to socket.error makes
> >sense.
> 
> OTOH, when os.read() returns an error, os.error (OSError) is raised.
> Is that not I/O?
> 
> IMO this is all hairsplitting, and the exact inheritance hierarchy for
> these doesn't matter much -- nobody is going to write a handler that
> treats OSError or socket.error different than IOError.

Ah.  Given all that, the point of a NetworkIOError is moot.  I had
assumed read would raise an IOError but hadn't read the code.  Looks
like fileobject.c's file_read() raises IOError as I expected but
posixmodule.c's read() raises OSError (fair enough, its the os module).

Since socket objects are treated like file objects in many cases I
think IOError would be a more appropriate parent than
EnvironmentError.  There was a case at work recently that started me
down the path of looking at this where code caught IOError but not
socket.error.

Any objects to me just having socket.error inherit from IOError?

> >PS for the person complaining that the url didn't work.  blame
> >   sourceforge and go look the bug up by id yourself.  nothing i can
> >   do about that.
> 
> Try python.org/sf/1706815
> 
> --Guido

ooo handy.  thanks.

-Greg