iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix use of "either" and typo in "checking" (Jim Jewett)

This commit is contained in:
Antoine Pitrou 2011-04-04 15:33:34 +02:00
parent 32da320e75
commit c842b6b33b
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
pep-3151.txt
View File

@ -83,12 +83,12 @@ caught but not IOError, or the reverse.
A further proof of the ambiguity of this segmentation is that the standard
library itself sometimes has problems deciding. For example, in the
``select`` module, similar failures will raise either ``select.error``,
``OSError`` or ``IOError`` depending on whether you are using select(),
a poll object, a kqueue object, or an epoll object. This makes user code
uselessly complicated since it has to be prepared to catch various
exception types, depending on which exact implementation of a single
primitive it chooses to use at runtime.
``select`` module, similar failures will raise ``select.error``, ``OSError``
or ``IOError`` depending on whether you are using select(), a poll object,
a kqueue object, or an epoll object. This makes user code uselessly
complicated since it has to be prepared to catch various exception types,
depending on which exact implementation of a single primitive it chooses
to use at runtime.
As for WindowsError, it seems to be a pointless distinction. First, it
only exists on Windows systems, which requires tedious compatibility code
@ -171,10 +171,10 @@ a narrower type of compatibility, which we will call *useful compatibility*.
For this we first must explain what we will call *careful* and *careless*
exception handling. *Careless* (or "naïve") code is defined as code which
blindly catches either of ``OSError``, ``IOError``, ``socket.error``,
``mmap.error``, ``WindowsError``, ``select.error`` without cheking the ``errno``
blindly catches any of ``OSError``, ``IOError``, ``socket.error``,
``mmap.error``, ``WindowsError``, ``select.error`` without checking the ``errno``
attribute. This is because such exception types are much too broad to signify
anything. Either of them can be raised for error conditions as diverse as: a
anything. Any of them can be raised for error conditions as diverse as: a
bad file descriptor (which will usually indicate a programming error), an
unconnected socket (ditto), a socket timeout, a file type mismatch, an invalid
argument, a transmission failure, insufficient permissions, a non-existent