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

[Georg Brandl]

Am 11.11.2010 16:03, schrieb M.-A. Lemburg:
> Antoine Pitrou wrote:
>> On Thu, 11 Nov 2010 22:03:36 +1000
>> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>
>>> This issue is addressed directly in the PEP by the "Compatibility
>>> Strategy" section. Code which checks errno will not suddenly start
>>> catching additional exceptions due to the merger of IOError and
>>> OSError.
>>>
>>> However, I agree with you that the PEP would benefit from keeping
>>> socket.error, select.error and mmap.error as separate IOError
>>> subclasses. Existing code may legitimately be catching those in try
>>> blocks that include other unrelated operations that may raise IOError.
>> 
>> Most socket I/O errors use different errnos (socket-specific errnos such
>> as ECONNRESET, etc.), so merging the exception classes wouldn't change
>> anything for careful code which checks the errno.
>> 
>> As for mmap.error, I think it's a design mistake in the first place,
>> since mmap'ed files are not consistently different from normal files.
>> 
>> As for select.error, the way the select module itself is generally
>> inconsistent in which exceptions it raises also makes me think it is a
>> design or implementation bug. The fact that it doesn't even inherit
>> EnvinromentError reinforces that feeling.
>> 
>> More fundamentally, the effort to create a detailed IO exception
>> hierarchy is much less useful if we keep islands such as socket.error,
>> mmap.error, since those errors won't benefit. The PEP only achieves
>> maximum usefulnesss if it can leverage a single IO exception base
>> class.
> 
> Why ? You can use multiple inheritance to plug the existing
> class structure into a new one.
> 
>> 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.

Georg