How do OSError subclasses such as FileNotFoundError relate to errno?

## What the tree looked like before Operating-system failures arrive in Python as `OSError`. Historically that was all the information the class gave you: a single flat type covering a missing file, a permission denial, a broken pipe and a refused connection alike. To distinguish them you caught the base class and inspected the numeric `errno` attribute against constants from the `errno` module: ```python import errno try: open("/no/such/file") except OSError as err: if err.errno != errno.ENOENT: raise ``` That pattern worked but was noisy, easy to get wrong, and inverted the normal shape of Python error handling: you caught broadly and then re-raised what you did not want, instead of naming what you did. ## PEP 3151 and the subclasses Python 3.3 reorganised this. The common `errno` values were given dedicated `OSError` subclasses, and the interpreter selects the right class when it constructs the exception. The ones worth knowing by name: * `FileNotFoundError`, `FileExistsError` * `PermissionError` * `IsADirectoryError`, `NotADirectoryError` * `NotImplementedError` is *not* one of these — it is a `RuntimeError` subclass, a common trip-up * `InterruptedError`, `BlockingIOError`, `ChildProcessError`, `ProcessLookupError` * `TimeoutError` * `ConnectionError`, with `ConnectionResetError`, `ConnectionRefusedError`, `ConnectionAbortedError` and `BrokenPipeError` beneath it Because exception matching is by class, this is purely additive for callers. `except OSError` still catches every one of them — useful at a boundary where any filesystem failure means the same thing. `except FileNotFoundError` narrows to exactly the case you can recover from. And `except ConnectionError` catches the whole family of socket teardown failures without listing four classes. The same PEP collapsed the old aliases: `IOError`, `EnvironmentError` and `WindowsError` are the same object as `OSError`, not separate classes. Code that catches `IOError` is catching `OSError` under another spelling, which is why modern code simply writes `OSError`. ## errno did not go away The subclasses cover the common codes, not all of them. The instance still carries the raw data: * `errno` — the numeric code, comparable against `errno.ENOENT`, `errno.EACCES` and friends * `strerror` — the operating system's message for that code * `filename` and `filename2` — the paths involved, when the failing call had them So the modern pattern is layered: name the subclass when one exists, and fall back to catching `OSError` and testing `errno` for codes such as `ENOSPC` (no space left on device) or `EXDEV` (cross-device link) that have no dedicated class. Note that `errno` is `None` on `OSError` instances constructed by hand or raised by code that did not come from a real system call, so a comparison should tolerate that. ```python import errno try: open("/no/such/file") except FileNotFoundError as err: print(isinstance(err, OSError), err.errno == errno.ENOENT, err.filename) ``` ## Portability caveats The mapping from an operating-system condition to a Python class runs through `errno`, and the platforms do not agree perfectly. Opening a directory as a file raises `IsADirectoryError` on Linux but succeeds or fails differently elsewhere; a connection torn down mid-transfer may surface as `ConnectionResetError` on one platform and `BrokenPipeError` on another. The defensive habit is to catch the family (`ConnectionError`, or `OSError` itself) at boundaries where you only need to know that the operation failed, and to reserve the narrow classes for cases where recovery genuinely differs — for example, treating a missing file as "create it" and a permission denial as "stop and report". ## TimeoutError is shared `TimeoutError` is a built-in `OSError` subclass, originally for the `ETIMEDOUT` system error. Python 3.11 made the asynchronous timeout error the same class: `asyncio.TimeoutError` is now an alias of the built-in, and `socket.timeout` had already become one in 3.10. That means a single `except TimeoutError` covers a blocking socket timeout and an awaited operation that timed out, which is a small but frequently-missed simplification when modernising older code. ## What an interviewer is checking That you write `except FileNotFoundError` rather than an `errno` comparison; that you know the base class still catches everything, so narrowing is a choice and not a risk; that you can reach for `errno` when the code has no dedicated subclass; and that you do not confuse `NotImplementedError` — which is a `RuntimeError` — with anything in this family. ## Reading a code you do not recognise The `errno` module also carries `errorcode`, a mapping from the numeric value back to its symbolic name, so `errno.errorcode[err.errno]` turns an unfamiliar number in a log into something searchable, and `os.strerror` renders the platform's message for a code you already hold. In practice, logging the exception's class name alongside `errno` and `filename` is enough to reconstruct a filesystem failure after the fact without reproducing it — which matters, because these are exactly the failures that depend on the state of a machine you no longer have in front of you.