Adding NetworkIOError for bug 1706815
In response to bug 1706815 and seeing messy code to catch errors in network apps I've implemented most of the ideas in the bug and added a NetworkIOError exception (child of IOError). With this, socket.error would now inherit from NetworkIOError instead of being its own thing (the old one didn't even declare a parent!). Complete patch attached to the bug. All unit tests pass. Documentation updates included. http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470 Any thoughts? I'm happy with it and would like to commit it if folks agree.
Why not simply inherit socket.error from EnvironmentError? On 7/4/07, Gregory P. Smith <greg@electricrain.com> wrote:
In response to bug 1706815 and seeing messy code to catch errors in network apps I've implemented most of the ideas in the bug and added a NetworkIOError exception (child of IOError). With this, socket.error would now inherit from NetworkIOError instead of being its own thing (the old one didn't even declare a parent!).
Complete patch attached to the bug. All unit tests pass. Documentation updates included.
http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470
Any thoughts? I'm happy with it and would like to commit it if folks agree.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
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. The patch makes URLError a child of NetworkIOError instead of IOError. Does that make sense? URLs as an abstract concept may or may not imply network I/O behind the scenes though network i/o is the most common use. I could take that argument further and suggest they don't necessarily even imply actual I/O if you've provided your own protocol handlers. The question then becomes if there are any use cases for "except NetworkIOError:" that code wouldn't want to just use "except IOError:" for that using "except socket.error:" or "except urllib2.URLError:" are insufficient for. My intuition is telling me: probably not. urllib2 code should catch socket.error everywhere internally and turn it into a URLError (the code appears to do this in many places though i haven't audited that it does everywhere). -greg 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.
On 7/4/07, Gregory P. Smith <greg@electricrain.com> wrote:
In response to bug 1706815 and seeing messy code to catch errors in network apps I've implemented most of the ideas in the bug and added a NetworkIOError exception (child of IOError). With this, socket.error would now inherit from NetworkIOError instead of being its own thing (the old one didn't even declare a parent!).
Complete patch attached to the bug. All unit tests pass. Documentation updates included.
http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470
Any thoughts? I'm happy with it and would like to commit it if folks agree.
On 7/5/07, Gregory P. Smith <greg@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. (If you have different call sites that raise different exceptions, each call site should have a separate try/except rather than a single try/except with multiple handlers.)
The patch makes URLError a child of NetworkIOError instead of IOError. Does that make sense? URLs as an abstract concept may or may not imply network I/O behind the scenes though network i/o is the most common use. I could take that argument further and suggest they don't necessarily even imply actual I/O if you've provided your own protocol handlers.
Well, as long as NetworkIOError inherits from IOError, the change is compatible, but I don't think anyone would care. Making URLError a child of EnvironmentError or socket.error could be defended too, and I doubt it makes a difference for any real code. (Anyone with evidence to the contrary, please speak up now).
The question then becomes if there are any use cases for "except NetworkIOError:" that code wouldn't want to just use "except IOError:" for that using "except socket.error:" or "except urllib2.URLError:" are insufficient for. My intuition is telling me: probably not. urllib2 code should catch socket.error everywhere internally and turn it into a URLError (the code appears to do this in many places though i haven't audited that it does everywhere).
Hm. I'm no fan of such renaming of exceptions (even though the __cause__ mechanism from PEP 3134 (formerly 344) makes it a little less problematic).
-greg
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
On 7/4/07, Gregory P. Smith <greg@electricrain.com> wrote:
In response to bug 1706815 and seeing messy code to catch errors in network apps I've implemented most of the ideas in the bug and added a NetworkIOError exception (child of IOError). With this, socket.error would now inherit from NetworkIOError instead of being its own thing (the old one didn't even declare a parent!).
Complete patch attached to the bug. All unit tests pass. Documentation updates included.
http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470
Any thoughts? I'm happy with it and would like to commit it if folks agree.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, Jul 05, 2007 at 12:05:01PM +0200, Guido van Rossum wrote:
On 7/5/07, Gregory P. Smith <greg@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
On Tue, 3 Jul 2007 23:58:44 -0700, "Gregory P. Smith" <greg@electricrain.com> wrote:
In response to bug 1706815 and seeing messy code to catch errors in network apps I've implemented most of the ideas in the bug and added a NetworkIOError exception (child of IOError). With this, socket.error would now inherit from NetworkIOError instead of being its own thing (the old one didn't even declare a parent!).
Complete patch attached to the bug. All unit tests pass. Documentation updates included.
http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470
FWIW, that page does not seem to be generally accessible. It's difficult to know what you're talking about without being able to see it. Artifact: Invalid ArtifactID; this Tracker item may have moved to a different Tracker since this URL was generated -- [Find the new location of this Tracker item] Following [Find the new location ...]: Artifact: This Artifact Has Been Made Private. Only Group Members Can View Private ArtifactTypes.
Any thoughts? I'm happy with it and would like to commit it if folks agree.
Jean-Paul
participants (3)
-
Gregory P. Smith -
Guido van Rossum -
Jean-Paul Calderone