On 7/5/07, Gregory P. Smith <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/) _______________________________________________ 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/archive%40mail-archive.com
