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

[M.-A. Lemburg]

Georg Brandl wrote:
>>> That said, it is obvious that this PEP can raise compatibility concerns
>>> for uncaring code (code which is already poorly written in the first
>>> place). 
>>
>> 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'
> 
> And as Antoine already showed, whether a given code that does I/O raises
> IOError or OSError is pretty much arbitrary.  I agree for socket.error
> though; there needs to be a catch-all way to intercept network exceptions.

I'm not sure where Antoine got this impression. Stdlib modules
traditionally always implemented a base error class for exceptions
specific to that module and sometimes also added subclasses
for additional breakdown.

The OSError originated in the os module's os.error and was
only raised for os module exceptions. With the introduction
of OSError as a builtin, other modules started using this
exception as well, which is a bit unfortunate. I still don't
find its use arbitrary, though.

IOError, OTOH, was used for exceptions raised by C lib I/O
related functions and operations. This was never tied to a single
module, but almost always used for typical I/O operations on
files, sockets, devices, etc.

As such, both depend on the runtime environment, hence the
EnvironmentError base class.

I also find assumptions such as "However, the user is interested in the nature of the error, not in
which part of the interpreter it comes from (since the latter is obvious from reading the traceback
message or application source code)." misleading.

Of course, the user is interested in which part of the interpreter an
exception originated and yes, she does want to take action on
the exception based on the context of origin. That was the whole
point why we added per module error base classes in the first
place.

Antoine can't really be serious when expecting the user to
run the exception by the inspect module to find that context,
e.g. to determine whether it was caused by a socket, an open
file, or an attempt to ask the file system for a directory
listing. All of these can e.g. raise an error with errno
EACCESS.

-- 
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/