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

[Nick Coghlan]

On Fri, Nov 12, 2010 at 1:03 AM, M.-A. Lemburg <mal at egenix.com> 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).

Trying to restore a consistent distinction between them is even more
of compatibility problem than simply giving up and merging them. I
thought the PEP already made this point, but it may not be as clear if
you don't already agree with the conclusion.

There is a slightly better case for keeping socket.error around since
we've been fairly consistent in having the networking code raise that
rather than a bare IOError. However, even there the value of the
distinction is blurring, since the other layers of the IO stack will
still raise IOError.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia