How does Python choose which except clause handles a raised exception?

The rule is short, and every interesting consequence follows from it: **Python runs the body of the first `except` clause, in source order, whose type matches the raised exception.** ## What "matches" means A clause `except E:` matches when the raised exception's class is `E` or any subclass of `E`. It is a class relationship, not an instance comparison, so the whole builtin hierarchy is available to you: `except OSError:` catches `FileNotFoundError`, `PermissionError` and the rest of the OS error family, and `except Exception:` catches essentially everything an application raises. The test is against the *class of the raised instance*. Note that `raise ValueError` with no call still produces an instance — Python instantiates the class for you — so there is never a class-versus-instance distinction to worry about at match time. ## First match, not best match This is the part interviewers probe. Python does not search for the most specific handler; it takes the first one that matches: ```python try: raise ValueError("boom") except Exception: print("broad clause won") # this runs except ValueError: print("never reached") ``` The second clause is unreachable. Python does not warn about it — the clause is perfectly valid code, and the interpreter has no obligation to prove it can run. A static analysis tool will usually flag it, which is one small reason to run one. The practical rule is to order clauses from specific to general, top to bottom, and to remember that the ordering is *your* responsibility, not the language's. Only one clause ever runs. There is no fall-through and no way for a handler to say "and also try the next one" — if you want the enclosing code to see the exception too, you re-raise it. ## Tuple clauses When several types deserve identical handling, one clause can name a parenthesized tuple: ```python try: value = parse(raw) except (ValueError, TypeError) as err: value = fallback(err) ``` The clause matches if the raised exception matches *any* member, and members are themselves matched by subclass, so a tuple can mix families freely. The parentheses are what make it a tuple expression; a list will not do. `except [ValueError, TypeError]:` compiles fine and then fails at match time with `TypeError: catching classes that do not inherit from BaseException is not allowed`, because Python checks the object it was handed, and a list is not an exception class. The same error appears if any member of the tuple is not a `BaseException` subclass — `except (ValueError, int):` fails even when the raised exception *is* a `ValueError`, because the whole clause is validated when the match runs. And note *when* that happens: these are runtime errors raised while handling another exception, so a typo in a rarely-taken handler can sit undetected for a long time. ## The `as` binding on a tuple clause A tuple clause takes an `as` target like any other, and the target is bound to the actual instance, so you can branch on its concrete type inside the body if the shared handling is only partly shared. The binding is deleted when the handler exits, so copy it out if you need it later. ## Practical ordering patterns A handler chain usually reads as a funnel: the narrowest, most expected failure first, then the family it belongs to, then a broad safety net if the code genuinely has one. Two habits keep the chain honest: 1. **Write the specific clauses first.** If you cannot say why a clause is above another, you probably do not need both. 2. **Group by handling, not by taxonomy.** Two exception types that produce the same recovery belong in one tuple clause; two that produce different recovery belong in separate clauses even if they share a base class. ## What a strong answer sounds like "Clauses are checked top to bottom; the first whose class matches the raised exception's class or one of its bases wins, and the rest are skipped. That is why a broad clause above a narrow one silently makes the narrow one dead. A single clause can name a parenthesized tuple to handle several types the same way, and every member has to be an exception class or the match itself raises a `TypeError`." That is the mechanism. How *broadly* you should be catching in the first place is a separate design conversation, and a good candidate keeps the two apart: this question is about which clause the interpreter picks, not about which clause you should have written.