令人困惑的作業系統相關異常集合

作業系統相關（或系統呼叫相關）異常目前是各種類別的集合，排列成以下子層次結構

+-- 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