令人困惑的 OS 相关异常集合

与 OS 相关（或与系统调用相关）的异常当前是各种类，排列在以下子层次结构中

+-- EnvironmentError
    +-- IOError
        +-- io.BlockingIOError
        +-- io.UnsupportedOperation (also inherits from ValueError)
        +-- socket.error
            +-- socket.gaierror
            +-- socket.herror
            +-- socket.timeout
    +-- OSError
        +-- VMSError
        +-- WindowsError
    +-- mmap.error
+-- select.error

虽然其中一些区别可以通过实现考虑来解释，但在更高层面上它们通常不是非常逻辑的。例如，OSError 和 IOError 之间的界限通常很模糊。考虑以下情况

>>> os.remove("fff")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 2] No such file or directory: 'fff'
>>> open("fff")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'fff'

相同的错误条件（不存在的文件）会根据调用的库函数转换为两种不同的异常。这样做的原因是 os 模块仅引发 OSError（或其子类 WindowsError），而 io 模块主要引发 IOError。但是，用户对错误的性质感兴趣，而不是它来自解释器的哪个部分（因为后者从阅读回溯消息或应用程序源代码中显而易见）。

事实上，很难想到任何应该捕获 OSError 但不捕获 IOError 或反之亦然的情况。

此细分模糊性的进一步证明是标准库本身有时在决策方面存在问题。例如，在 select 模块中，类似的故障将引发 select.error、OSError 或 IOError，具体取决于您是使用 select()、轮询对象、kqueue 对象还是 epoll 对象。这使得用户代码变得不必要地复杂，因为它必须准备好捕获各种异常类型，具体取决于它在运行时选择使用的单个原语的确切实现。

至于 WindowsError，它似乎是一个毫无意义的区别。首先，它仅存在于 Windows 系统上，这需要在跨平台应用程序中使用乏味的兼容代码（此类代码可以在 Lib/shutil.py 中找到）。其次，它继承自 OSError，并且对于与 OSError 在其他系统上引发的类似错误而引发。第三，希望访问低级异常细节的用户必须检查 errno 或 winerror 属性。

缺乏细粒度的异常

当前各种 OS 相关的异常不允许用户轻松过滤所需的故障类型。例如，考虑删除存在的文件的任务。先检查后行动（LBYL）习语存在明显的竞争条件

if os.path.exists(filename):
    os.remove(filename)

如果另一个线程或进程在调用 os.path.exists 和 os.remove 之间创建了一个名为 filename 的文件，则不会删除它。这可能会导致应用程序中的错误，甚至安全问题。

因此，解决方案是尝试删除文件，如果文件不存在则忽略错误（一种称为“出错后求原谅，总比事前请求许可容易”或 EAFP 的习语）。谨慎的代码将如下所示（在 POSIX 和 Windows 系统下均有效）

try:
    os.remove(filename)
except OSError as e:
    if e.errno != errno.ENOENT:
        raise

甚至

try:
    os.remove(filename)
except EnvironmentError as e:
    if e.errno != errno.ENOENT:
        raise

这需要输入更多内容，并且还迫使用户记住 errno 模块中的各种神秘助记符。它增加了额外的认知负担，并且很快就会变得令人厌烦。因此，许多程序员将改写以下代码，这会过分地静默异常

try:
    os.remove(filename)
except OSError:
    pass

os.remove 不仅在文件不存在时引发 OSError，而且在其他可能的情况下也会引发 OSError（例如，文件名指向目录，或当前进程没有权限删除文件），所有这些都表明应用程序逻辑中的错误，因此不应被静默处理。程序员希望改写的内容类似于

try:
    os.remove(filename)
except FileNotFoundError:
    pass

理由

第一步不仅为用户提供了如 基本原理 部分所述的更简单的环境，而且还允许更好地更完整地解决 步骤 2（请参阅 先决条件）。

保留 OSError 作为通用 OS 相关异常的官方名称的基本原理是，它恰恰比 IOError 更通用。EnvironmentError 键入起来更麻烦，而且知名度也低得多。

在附录 B中的调查显示，IOError 是目前标准库中最主要的错误类型。对于第三方 Python 代码，Google 代码搜索显示 IOError 在用户代码中比 EnvironmentError 常见十倍，比 OSError 常见三倍[3]。然而，由于没有计划在中期弃用 IOError，因此 OSError 的流行度较低并不是问题。

异常属性

由于 WindowsError 已合并到 OSError 中，后者在 Windows 下获得了一个winerror属性。在不具有意义的情况下，它被设置为 None，这与errno、filename和strerror属性（例如，当 OSError 由 Python 代码直接引发时）的情况相同。

名称弃用

以下段落概述了旧异常名称可能的弃用策略。但是，目前已决定将其保留为别名。这一决定可能会在 Python 4.0 发布之前进行修改。

先决条件

步骤 1是对此的一个宽松的前提条件。

前提条件，因为某些 errno 目前可以附加到不同的异常类：例如，ENOENT 可以附加到 OSError 和 IOError，具体取决于上下文。如果我们不想破坏有用的兼容性，我们就不能使except OSError（或 IOError）无法匹配在今天可以成功匹配的异常。

宽松，因为如果现有异常类未合并，我们可以决定对步骤 2 进行部分解决：例如，ENOENT 可以引发假设的 FileNotFoundError（以前引发 IOError 的地方），但在其他情况下继续引发 OSError。

如果新的子类使用多重继承来匹配所有现有的超类（或至少是 OSError 和 IOError，它们可以说是最普遍的），则可以完全消除对步骤 1 的依赖。但是，这将使层次结构更加复杂，因此用户更难理解。

新的异常类

以下初步的子类列表，以及描述和映射到它们的 errno 列表，提交讨论

• FileExistsError：尝试创建已存在的文件或目录（EEXIST）
• FileNotFoundError：在所有请求文件和目录但不存在的情况下（ENOENT）
• IsADirectoryError：在目录上请求文件级操作（open()、os.remove()…）（EISDIR）
• NotADirectoryError：在其他内容上请求目录级操作（ENOTDIR）
• PermissionError：尝试运行操作但没有足够的访问权限 - 例如文件系统权限（EACCES、EPERM）
• BlockingIOError：操作将在设置为非阻塞操作的对象（例如套接字）上阻塞（EAGAIN、EALREADY、EWOULDBLOCK、EINPROGRESS）；这是现有的io.BlockingIOError，具有扩展的作用
• BrokenPipeError：尝试写入管道但另一端已关闭，或尝试写入已关闭写入的套接字（EPIPE、ESHUTDOWN）
• InterruptedError：系统调用被传入信号中断（EINTR）
• ConnectionAbortedError：连接尝试被对等方中止（ECONNABORTED）
• ConnectionRefusedError：连接被对等方拒绝（ECONNREFUSED）
• ConnectionResetError：连接被对等方重置（ECONNRESET）
• TimeoutError：连接超时（ETIMEDOUT）；这可以被重新定义为通用的超时异常，替换socket.timeout，并且对其他类型的超时（例如 Lock.acquire() 中的超时）也很有用
• ChildProcessError：子进程操作失败（ECHILD）；这主要由 wait() 函数族引发。
• ProcessLookupError：给定的进程（例如，由其进程 ID 标识）不存在（ESRCH）。

此外，建议包含以下异常类

• ConnectionError：ConnectionAbortedError、ConnectionRefusedError和ConnectionResetError的基类

下图尝试总结提议的添加内容，以及相应的 errno 值（如果适用）。未显示子层次结构的根（OSError，假设步骤 1完全被接受）

+-- BlockingIOError        EAGAIN, EALREADY, EWOULDBLOCK, EINPROGRESS
+-- ChildProcessError                                          ECHILD
+-- ConnectionError
    +-- BrokenPipeError                              EPIPE, ESHUTDOWN
    +-- ConnectionAbortedError                           ECONNABORTED
    +-- ConnectionRefusedError                           ECONNREFUSED
    +-- ConnectionResetError                               ECONNRESET
+-- FileExistsError                                            EEXIST
+-- FileNotFoundError                                          ENOENT
+-- InterruptedError                                            EINTR
+-- IsADirectoryError                                          EISDIR
+-- NotADirectoryError                                        ENOTDIR
+-- PermissionError                                     EACCES, EPERM
+-- ProcessLookupError                                          ESRCH
+-- TimeoutError                                            ETIMEDOUT

命名

可能会出现各种命名争议。其中之一是所有异常类名是否都应该以“Error”结尾。支持者认为这与其余异常层次结构保持一致，反对者认为这过于冗长（特别是对于ConnectionAbortedError等长名称）。

异常属性

为了保持有用的兼容性，这些子类仍应为超类上定义的各种异常属性（例如errno、filename以及可选的winerror）设置适当的值。

实现

由于建议根据errno的值引发子类，因此扩展模块（标准或第三方）中应该不需要进行很少或根本不需要进行更改。

第一种可能性是调整PyErr_SetFromErrno()函数族（在 Windows 下为PyErr_SetFromWindowsErr()），以引发相应的 OSError 子类。但是，这无法涵盖使用以下习惯用法（在Lib/tempfile.py中可见）直接引发 OSError 的 Python 代码。

raise IOError(_errno.EEXIST, "No usable temporary file name found")

Marc-Andre Lemburg 提出的第二种可能性是调整OSError.__new__以实例化相应的子类。这样做的好处还在于涵盖了上述 Python 代码。

命名空间污染

使异常层次结构更细粒度会导致根（或 builtins）命名空间更大。但是，这需要适度，因为

• 仅建议添加少量额外的类；
• 虽然标准异常类型位于根命名空间中，但它们在视觉上通过使用 CamelCase 约定与众不同，而几乎所有其他内置类型都使用小写命名（除了 True、False、None、Ellipsis 和 NotImplemented）

另一种方法是提供一个包含更细粒度异常的单独模块，但这会违背鼓励谨慎代码而不是粗心代码的目的，因为用户首先必须导入新模块，而不是使用已可访问的名称。

模式匹配

另一种可能性是在捕获异常时引入高级模式匹配语法。例如

try:
    os.remove(filename)
except OSError as e if e.errno == errno.ENOENT:
    pass

此提案存在几个问题

• 它引入了新的语法，作者认为与重新设计异常层次结构相比，这是一个更大的变化。
• 它没有显著减少输入工作量。
• 它没有减轻程序员记住 errno 助记符的负担。

与 OSError 相关的常见错误码

• EBADF：错误的文件描述符（通常表示文件描述符已关闭）
• EEXIST：文件或目录已存在
• EINTR：中断的函数调用
• EISDIR：是一个目录
• ENOTDIR：不是一个目录
• ENOENT：没有这样的文件或目录
• EOPNOTSUPP：套接字不支持的操作（可能与现有的 io.UnsupportedOperation 混淆）
• EPERM：操作不被允许（例如，使用 os.setuid() 时）

与 IOError 相关的常见错误码

• EACCES：权限被拒绝（对于文件系统操作）
• EBADF：错误的文件描述符（使用 select.epoll）；对只写 GzipFile 进行读取操作，反之亦然
• EBUSY：设备或资源繁忙
• EISDIR：是一个目录（尝试打开时）
• ENODEV：没有这样的设备
• ENOENT：没有这样的文件或目录（尝试打开时）
• ETIMEDOUT：连接超时

与 socket.error 相关的常见错误码

所有这些错误也可能与普通的 IOError 相关联，例如，当在套接字的文件描述符上调用 read() 时。

• EAGAIN：资源暂时不可用（在非阻塞套接字调用期间，除了 connect()）
• EALREADY：连接已在进行中（在非阻塞 connect() 期间）
• EINPROGRESS：操作正在进行中（在非阻塞 connect() 期间）
• EINTR：中断的函数调用
• EISCONN：套接字已连接
• ECONNABORTED：连接被对等方中止（在 accept() 调用期间）
• ECONNREFUSED：连接被对等方拒绝
• ECONNRESET：连接被对等方重置
• ENOTCONN：套接字未连接
• ESHUTDOWN：传输端点关闭后无法发送
• EWOULDBLOCK：与 EAGAIN 相同的原因

与 select.error 相关的常见错误码

• EINTR：中断的函数调用

关于 VMSError

VMSError 完全未被解释器核心和标准库使用。它是由 Jean-François Piéronne 于 2002 年提交的 OpenVMS 补丁的一部分 [4]；包含 VMSError 的动机是它可以由第三方包引发。

解释器核心

处理 PYTHONSTARTUP 会引发 IOError（但错误会被丢弃）

$ PYTHONSTARTUP=foox ./python
Python 3.2a0 (py3k:82920M, Jul 16 2010, 22:53:23)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Could not open PYTHONSTARTUP
IOError: [Errno 2] No such file or directory: 'foox'

PyObject_Print() 当 ferror() 信号在 FILE * 参数（在源代码树中，始终是 stdout 或 stderr）上出现错误时，会引发 IOError。

使用 mbcs 编码进行 Unicode 编码和解码可能会在某些错误情况下引发 WindowsError。

标准库

>>> bz2.BZ2File("foox", "rb")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory
>>> bz2.BZ2File("LICENSE", "rb").read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: invalid data stream
>>> bz2.BZ2File("/tmp/zzz.bz2", "wb").read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: file is not ready for reading

>>> dbm.gnu.open("foox")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_gdbm.error: [Errno 2] No such file or directory

>>> imp.load_source("foo", "foo", 123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

>>> open("Python/", "r")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 21] Is a directory: 'Python/'

>>> open("LICENSE").write("bar")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: not writable
>>> io.StringIO().fileno()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: fileno
>>> open("LICENSE").seek(1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: can't do nonzero cur-relative seeks

>>> f = open("LICENSE")
>>> os.close(f.fileno())
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

>>> f = open("LICENSE")
>>> next(f)
'A. HISTORY OF THE SOFTWARE\n'
>>> f.tell()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: telling position disabled by next() call

>>> mmap.mmap(123, 10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
mmap.error: [Errno 9] Bad file descriptor
>>> mmap.mmap(os.open("/tmp", os.O_RDONLY), 10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
mmap.error: [Errno 13] Permission denied

>>> fd = os.open("LICENSE", os.O_RDONLY)
>>> m = mmap.mmap(fd, 16384)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 5] Accès refusé
>>> sys.last_value.errno
13
>>> errno.errorcode[13]
'EACCES'

>>> m = mmap.mmap(-1, 4096)
>>> m.resize(16384)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 87] Paramètre incorrect
>>> sys.last_value.errno
22
>>> errno.errorcode[22]
'EINVAL'

>>> ossaudiodev.open("foo", "r")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'foo'

>>> readline.read_history_file("foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory
>>> readline.read_init_file("foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory
>>> readline.write_history_file("/dev/nonexistent")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 13] Permission denied

>>> signal.alarm(1); select.select([], [], [])
0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
select.error: (4, 'Interrupted system call')
>>> e = sys.last_value
>>> e
error(4, 'Interrupted system call')
>>> e.errno == errno.EINTR
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'error' object has no attribute 'errno'
>>> e.args[0] == errno.EINTR
True