[Python-Dev] Adding NetworkIOError for bug 1706815
Gregory P. Smith
greg at electricrain.com
Sat Jul 7 01:01:10 CEST 2007
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
> 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
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
ooo handy. thanks.
More information about the Python-Dev