Re: [Python-ideas] PEP 3151 - Reworking the OS and IO exception hierarchy (again)

Nick Coghlan wrote:

On Fri, Nov 12, 2010 at 1:03 AM, M.-A. Lemburg wrote:

...

There's nothing wrong with code such as this:

try: ... except socket.error: print 'Network problem' except IOError: print 'File I/O problem' except OSError: print 'File system problem'

You probably have a different use of try-except in mind. Those exception handling blocks are used at various levels in an application and the code run between try-except may well be dealing with sockets and file I/O, but require two different sets of problem resolution or reporting implementations.

The PEP breaks such code.

No, that's the kind of code we're saying is already subtly broken, and we're just changing the way it is broken to be far more obvious (instead of *sometimes* printing the wrong message based on exactly what went wrong, it will instead consistently print the message associated with whichever of IOError and OSError is listed first). The standard library may have been consistent about IOError vs OSError at one point in time, but that time is in the past. Any code which doesn't catch (or ignore) them both and treat them as equivalent to each other is either already broken (if the try block contains code which may raise either exception) or won't be affected by the proposal in the PEP (if the try block is guaranteed to raise only the exception type already caught by the try block).

I don't follow you. Example: If I run code that e.g. uses os.fork() and get an IOError, I don't want to catch that, since this is likely a programming error of some sort which I don't want to mask. However, if I get an OSError (the error raised by os.fork()), I can report this as a resource problem to higher level code which can then take appropriate action. Your arguing that because the stdlib has blurred the distinction between IOError and OSError (as a result of making OSError builtin rather than letting it live in the os module), it is OK to now blur the distinction between error handling code that was meant to run for issues that are related to the actually used functions and possibly causing the error reporting to malfunction. Antoine is arguing that simply by relying on the errno you can write "careful" code. That's not correct. If I write code that only checks the errno without knowing in which context this was set, I cannot always make assumptions on what that errno really means, e.g. EACCES, EBADF or EPERM are used by lots of C lib and OS functions, so there's no implicit hint to the subsystem where the error originated. If we go down that route, we might as well merge TypeError into ValueError as well, since the distinction between those has been blurred long before OSError was even introduced. But we don't do that. And the reason is that we know which functions or methods return which types of errors and use that knowledge to direct the flow of error handling into the right lanes. Besides, there are lots of functions in the os module that don't do any I/O in the standard sense - why should those raise an IOError ? Most of the functions deal with OS services, so the name OSError is a lot more appropriate. Note that the same kind of blurring is likely going to happen for the newly suggested additional exceptions. Sooner or later people are going to use ConnectionError for all kinds of connections, not only socket-related ones. Same for TimeoutError and PermissionError. So in the end, you have to go and check the errno code again, just to see whether the exception you're looking at really originated from a socket or file operation which set errno, provided .errno isn't set to the E-values mentioned in the PEP per default... or we just merge everything back again into IOError and leave it to the programmers to find some other way to signal where the exception originated. Not very helpful. Perhaps it's indeed better to clearly draw the line between IOError and OSError again, like you say, instead of trying to "fix" things by further blurring information. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 11 2010)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/