A CLI wrapped in `except BaseException` finishes normally despite calling sys.exit(1) -- what is the handler catching?

### The call that is not a call `sys.exit(1)` does not ask the operating system to end the process. It **raises** an exception: `SystemExit`, with the value you passed stored on the instance's `code` attribute. Ending the process is what happens *after* that exception travels all the way up the call stack without being handled — the interpreter unwinds every frame, runs interpreter shutdown, and only then reports a status to the shell. Anything that stops the exception on the way up cancels the exit, exactly the way catching a `ValueError` cancels the error it represents. That is the whole mechanism behind the symptom. A CLI whose `main()` is called inside a `try` with an overbroad handler never gets to unwind, because the handler caught the exit request and then returned normally. Execution resumes after the `try` statement, the script runs to its end, and the process finishes with status `0` — success — even though the code explicitly asked for failure. ### Why `except Exception` is immune and the broad forms are not Python's exception tree is rooted at `BaseException`. `Exception` is one subclass of it, and almost every error you write handlers for — `ValueError`, `OSError`, `KeyError` — lives under `Exception`. A small set of classes deliberately sits *beside* `Exception`, directly under `BaseException`: `SystemExit`, `KeyboardInterrupt` and `GeneratorExit`. They are not application errors; they are the runtime's own control signals — "stop this program", "the user interrupted", "this generator is being closed". The split exists precisely so the everyday idiom `except Exception` is safe. It matches only the error branch and structurally cannot see a shutdown request. Two spellings defeat that protection: - a **bare** `except:`, which matches *anything*, including everything under `BaseException`; - `except BaseException`, which is the same reach spelled out. You can verify the relationship in one line — `issubclass(SystemExit, Exception)` is `False`, and `SystemExit.__mro__` is `(SystemExit, BaseException, object)`. ### What this looks like in production The failure is quiet, which is what makes it dangerous. A validation step calls `sys.exit(1)`, the wrapper prints "unexpected error: 1" or nothing at all, the script continues into work that should never have run, and the automation calling it sees a zero status and marks the step green. Scheduled jobs are the classic victim: the batch reports success while having written partial output. The standard library raises `SystemExit` from places people forget are exit points. `argparse` raises it when arguments do not parse and when `--help` is handled, so a broad handler wrapped around argument parsing turns a usage error into a program that carries on with unvalidated inputs. Any helper you call may legitimately exit, and a handler that catches `BaseException` silently takes that right away from every function beneath it. The same base class fact is why such a handler also eats `KeyboardInterrupt`, which is how a program becomes unkillable with Ctrl-C. ### Fixing it Narrow the clause. In the overwhelming majority of top-level wrappers the correct handler is: ```python try: main() except Exception: logging.exception("unhandled failure") sys.exit(1) ``` `except Exception` reports genuine bugs and leaves the control signals alone: a `SystemExit` from inside `main()` passes straight through and does what it was asked to do. If you genuinely need the widest reach — a supervisor that must log *anything* before dying — let the control signals out with an earlier, more specific clause, because clauses are tried in source order and the first match wins: ```python try: main() except (SystemExit, KeyboardInterrupt): raise except BaseException: logging.exception("fatal") raise ``` A third option is structural: move the exit call outside the guarded region. Have `main()` *return* a status and call `sys.exit(status)` after the `try` statement, so no handler is ever in a position to intercept it. Libraries especially should prefer this — raising a domain exception the caller can decide about beats calling `sys.exit()` in code you do not own the process of. ### The bits that are not this question's job The exception instance carries the requested status on `code`; what the interpreter finally does with that value — what status the shell sees, how a `None` or a string is treated — is the exit-status story, separate from the handler question here. And note that `finally` clauses still run either way; catching the exception changes *whether the program exits*, not whether cleanup happens. ### How to answer this in an interview Say the three linked facts in order and you have covered it: `sys.exit()` raises rather than exits; `SystemExit` derives from `BaseException`, not `Exception`; therefore a bare `except:` or an `except BaseException` swallows the exit and the process finishes with status `0`. Then name the fix — `except Exception`, or re-raise the control signals ahead of the broad clause — and mention that the same reasoning applies to Ctrl-C. Being able to say *why* the hierarchy is shaped that way, and not merely that it is, is what separates a memorised answer from an understood one.