令人困惑的操作系统相关异常集合

操作系统相关（或系统调用相关）异常目前是各种类别的集合，排列成以下子层次结构

+-- 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()、poll 对象、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，在其他可能的情况下也会引发（例如，文件名指向目录，或者当前进程没有删除文件的权限），这些都表明应用程序逻辑中存在错误，因此不应被静默。程序员更愿意编写的代码应该是这样的

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 可能在以前引发 IOError 的情况下引发假设的 FileNotFoundError，但在其他情况下继续引发 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 子类。但是，这不会涵盖直接引发 OSError 的 Python 代码，例如以下常见用法（在 Lib/tempfile.py 中可见）

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

Marc-Andre Lemburg 提出的第二种可能性是调整 OSError.__new__ 以实例化适当的子类。这具有同时涵盖上述 Python 代码的优点。

命名空间污染

使异常层次结构更细粒度会使根（或内置）命名空间更大。然而，这需要适度，因为

• 仅提出了少数附加类；
• 虽然标准异常类型存在于根命名空间中，但它们通过使用驼峰命名法与其他内置函数在视觉上有所区别，而几乎所有其他内置函数都使用小写命名（除了 True、False、None、Ellipsis 和 NotImplemented）

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

模式匹配

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

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

此提案的几个问题

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

与 OSError 相关的常见 errno

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

与 IOError 相关的常见 errno

• EACCES：权限被拒绝（用于文件系统操作）
• EBADF：错误的文件描述符（与 select.epoll）；对只写 GzipFile 进行读操作，反之亦然
• EBUSY：设备或资源忙
• EISDIR：是目录（尝试 open() 时）
• ENODEV：无此类设备
• ENOENT：无此类文件或目录（尝试 open() 时）
• ETIMEDOUT：连接超时

与 socket.error 相关的常见 errno

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

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

与 select.error 相关的常见 errno

• 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