How do ExceptionGroup and BaseExceptionGroup differ, and when do you need the base one?

### The hierarchy, in one line each Python's ordinary exception hierarchy separates `Exception` — errors your program is meant to handle — from the rest of `BaseException`: `KeyboardInterrupt`, `SystemExit`, `GeneratorExit`, and by convention `asyncio.CancelledError`, which are control-flow signals a broad handler must not swallow. Exception groups mirror that split exactly: * `BaseExceptionGroup` derives from `BaseException`. It can hold any exception at all. * `ExceptionGroup` derives from **both** `BaseExceptionGroup` and `Exception`. It can hold only instances of `Exception`. The MRO is `ExceptionGroup -> BaseExceptionGroup -> Exception -> BaseException -> object`, so an `ExceptionGroup` is a `BaseExceptionGroup`, but not the other way round. ### The constructor narrows for you A detail worth knowing because it removes a class of bugs: `BaseExceptionGroup.__new__` inspects the members, and if every one of them is an `Exception` it returns an `ExceptionGroup` instead: ```python g = BaseExceptionGroup('m', [ValueError('a')]) type(g).__name__ # 'ExceptionGroup' isinstance(g, Exception) # True ``` That means generic code — a helper that collects failures from a fan-out and raises them together — can always construct `BaseExceptionGroup` and still hand ordinary callers a catchable `ExceptionGroup` in the common case, without inspecting the members itself. The reverse is enforced rather than silently coerced. `ExceptionGroup('m', [KeyboardInterrupt()])` raises `TypeError: Cannot nest BaseExceptions in an ExceptionGroup`. There is no way to sneak a control-flow signal into a group that `except Exception` would catch, which is precisely the guarantee the split exists to give. ### Where the difference bites Suppose a fan-out is interrupted partway: some children failed with ordinary errors, and one was cancelled. The group that propagates must be a `BaseExceptionGroup`, because it holds an `asyncio.CancelledError`. Now: * `except Exception:` does **not** catch it. A broad "log and continue" handler higher up will not run, and the cancellation continues to propagate — correct behaviour, and a common surprise. * `except ExceptionGroup:` does not catch it either, for the same reason. Code that means "any group" must say `except BaseExceptionGroup:`. * `except* Exception:` matches the ordinary members and hands them over, while the `CancelledError` stays unmatched and is re-raised as a `BaseExceptionGroup` after the try statement. You get to clean up after the real errors without accidentally cancelling the cancellation. The same reasoning applies to `KeyboardInterrupt` during a batch and to `SystemExit` raised from a worker: the group type follows its worst member, and broad handlers stay honest. ### Practical rules * Raise `ExceptionGroup` when you are aggregating ordinary errors — validation failures, per-item processing errors. That is nearly always what you want, and callers can catch it with `except Exception`. * Use `BaseExceptionGroup` when the members can include control-flow signals, or when writing generic aggregation code where you cannot know; the constructor will narrow to `ExceptionGroup` whenever the contents allow. * In cleanup and top-level supervision code, catch `BaseExceptionGroup`, not `ExceptionGroup`, or you will miss exactly the cases where cleanup matters most. Then re-raise: catching a group that carries a cancellation and not putting it back is how a service becomes unstoppable. * Do not test group-ness with `type(eg) is ExceptionGroup`. Use `isinstance(eg, BaseExceptionGroup)`, which covers both builtins and any subclass, including the ones a library defines to carry extra state. ### Catching broadly, deliberately `except* BaseException` does match a cancellation or a `KeyboardInterrupt` sitting inside a group, and it is occasionally the right tool — a supervisor that must record every terminated child before letting the signal continue on its way. Treat it exactly as you treat a bare `except BaseException`: handle, do not swallow, and end the clause with a bare `raise` so the subgroup rejoins the leftovers and keeps propagating. The narrower and far more common form is `except* Exception` around the errors you actually own, leaving control-flow signals to the layer that asked for them. ### Subclassing Both types can be subclassed, which is how a library ships a domain-specific group. A subclass of `ExceptionGroup` must accept the `(message, exceptions)` pair, and if it carries extra state it should override `derive`, the hook that `split` and `subgroup` call when they build the partial groups — otherwise the extra state is lost the first time somebody splits your group. A subclass of `BaseExceptionGroup` alone does not get the automatic narrowing; that behaviour belongs to the base constructor deciding between the two builtins. ### Version note Both builtins arrived in Python 3.11 (PEP 654), including the constructor narrowing and the `TypeError` on nesting a `BaseException` in an `ExceptionGroup`. Nothing here changed through 3.14.