Errors Done Right: A Practical Deep Dive into Python Exceptions, Chaining, and Exception Groups

Every Python program eventually meets something it did not expect: a missing file, a malformed number, a network hiccup, a key that isn't in the dictionary. How you handle those moments is the difference between software that fails loudly and clearly and software that fails silently, corrupts data, or buries the real problem under a wall of confusing output. Exceptions are Python's built-in mechanism for exactly this, but most tutorials stop at try/except and move on. That's a shame, because Python's exception machinery is rich, expressive, and — since version 3.11 — capable of handling several unrelated failures at once.

This guide walks through the parts that actually matter in day-to-day code: the full try statement, the "ask forgiveness" philosophy, building your own exception types, preserving context when you re-raise, and the modern ExceptionGroup/except* feature. Every non-3.11 snippet here was run on CPython to confirm its output.

The full try statement: else and finally

Most people know try and except. Fewer use the two other clauses that complete the picture. The else block runs only when the try block did not raise, and finally runs no matter what — success, exception, or even a return. The else clause is valuable because it keeps the "happy path" code out of the try, so you don't accidentally catch exceptions from code that was never meant to be guarded.

def parse_ratio(text):
    try:
        num, denom = text.split("/")
        result = int(num) / int(denom)
    except ValueError:
        print("bad format or non-integer")
        return None
    except ZeroDivisionError:
        print("denominator was zero")
        return None
    else:
        print("parsed cleanly")
        return result
    finally:
        print("done attempting parse")

parse_ratio("10/2")   # parsed cleanly / done attempting parse -> 5.0
parse_ratio("10/0")   # denominator was zero / done attempting parse -> None
parse_ratio("x/2")    # bad format or non-integer / done attempting parse -> None

Notice the order of the except clauses. Python checks them top to bottom and runs the first one that matches, so put more specific exceptions before their parents. A single clause can catch several types by using a tuple:

def safe_int(x):
    try:
        return int(x)
    except (ValueError, TypeError):
        return None

print(safe_int("5"), safe_int("x"), safe_int(None))   # 5 None None

A word of caution about finally

Because finally always runs, a return (or break) inside it will silently override a return or a propagating exception from the try block. That is almost never what you want, so keep finally for cleanup — closing resources, releasing locks — and avoid control-flow statements inside it.

EAFP: ask forgiveness, not permission

Many languages encourage "look before you leap" (LBYL): check that a key exists before reading it, check a file exists before opening it. Python idiom leans the other way, toward EAFP — "easier to ask forgiveness than permission." You simply attempt the operation and catch the failure. This avoids race conditions (the file could vanish between your check and your open) and is often cleaner:

d = {"a": 1}

# LBYL
if "b" in d:
    value = d["b"]
else:
    value = 0

# EAFP — idiomatic
try:
    value = d["b"]
except KeyError:
    value = 0

The rule of thumb: catch the narrowest exception that represents the failure you actually expect. A bare except: or except Exception: around a large block will swallow bugs like typos in variable names (NameError) and make debugging miserable.

Building your own exception types

Custom exceptions turn vague failures into named, catchable events. Subclass Exception (never BaseException directly — that's reserved for things like KeyboardInterrupt), and give related errors a shared base class so callers can catch the whole family with one clause.

class ConfigError(Exception):
    """Base for all configuration problems."""

class MissingKeyError(ConfigError):
    def __init__(self, key):
        super().__init__(f"missing required key: {key!r}")
        self.key = key

try:
    raise MissingKeyError("database_url")
except ConfigError as exc:          # catches the base, so any ConfigError works
    print(type(exc).__name__, "->", exc)
    print("offending key:", exc.key)

Attaching structured data (like self.key) to the exception is far more useful than stuffing everything into the message string, because the handler can inspect and react to it programmatically.

Chaining: keep the original cause

A common mistake is catching a low-level error and raising a friendlier one, thereby throwing away the original traceback. Python solves this with exception chaining. When you write raise NewError(...) from original, Python records the original on the new exception's __cause__ attribute and prints both tracebacks, joined by "The above exception was the direct cause…".

def load_port(raw):
    try:
        return int(raw)
    except ValueError as exc:
        raise ConfigError("port must be an integer") from exc

try:
    load_port("abc")
except ConfigError as exc:
    print(exc)                 # port must be an integer
    print(repr(exc.__cause__)) # ValueError("invalid literal for int()...")

Even if you forget from, Python performs implicit chaining: any exception raised while handling another is automatically linked via __context__. Explicit chaining with from is still better because it communicates intent. And when the underlying error is an implementation detail you deliberately want to hide, suppress the chain with from None:

def load_port(raw):
    try:
        return int(raw)
    except ValueError:
        raise ConfigError("port must be an integer") from None

Re-raising without losing the traceback

Sometimes you want to log an error at the point it happens and still let it propagate. Use a bare raise inside the handler — it re-raises the current exception with its original traceback intact. Pair it with logging.exception(), which records the full traceback automatically:

import logging
log = logging.getLogger("demo")

def process(item):
    try:
        return 100 / item
    except ZeroDivisionError:
        log.exception("failed to process %r", item)
        raise   # bare raise: same exception, same traceback, keeps propagating

Writing raise exc instead of a bare raise works too, but it can rewrite the traceback's starting point, so prefer the bare form when you simply want to re-throw.

contextlib.suppress for the "I genuinely don't care" case

Occasionally an exception really is safe to ignore — deleting a file that may already be gone, for instance. Instead of an empty except block, contextlib.suppress expresses the intent clearly and concisely:

import os
import contextlib

with contextlib.suppress(FileNotFoundError):
    os.remove("/tmp/maybe-not-there")
# no error even if the file was already missing

Use it sparingly and always with a specific exception type. suppress(Exception) is just a bare except in disguise.

Exception groups: many failures at once (Python 3.11+)

Traditional exceptions model a single point of failure. But some operations fail in several ways simultaneously — think of validating a form with multiple bad fields, or gathering results from a batch of concurrent tasks where three of them raised. Python 3.11 introduced ExceptionGroup to bundle multiple exceptions into one object, and a new except* syntax to handle them by type.

# Python 3.11+
def validate(record):
    errors = []
    if not record.get("name"):
        errors.append(ValueError("name is required"))
    if record.get("age", 0) < 0:
        errors.append(ValueError("age must be non-negative"))
    if "@" not in record.get("email", ""):
        errors.append(TypeError("email looks malformed"))
    if errors:
        raise ExceptionGroup("validation failed", errors)

try:
    validate({"age": -1, "email": "nope"})
except* ValueError as eg:
    print("value problems:", [str(e) for e in eg.exceptions])
except* TypeError as eg:
    print("type problems:", [str(e) for e in eg.exceptions])

Each except* clause receives an ExceptionGroup containing only the sub-exceptions that matched its type, and — crucially — more than one clause can run for a single group. This is a real departure from ordinary except, where exactly one branch fires. Exception groups are also what asyncio.TaskGroup raises when several concurrent tasks fail together, so you'll meet them naturally in async code.

If you're on 3.11 or newer, another small but handy addition is Exception.add_note(), which lets you attach extra context to an exception as it travels up the stack without altering its type or message.

Practical guidelines

A few habits keep exception handling clean. Catch specific types, not blanket Exception, so real bugs surface instead of hiding. Keep try blocks small and push the non-risky code into else. Never write an except that only does pass — if you truly mean to ignore something, say so with contextlib.suppress and a named type. When you translate a low-level error into a domain-specific one, chain it with from so the original cause survives. And reserve exceptions for exceptional conditions; using them for ordinary control flow (like ending a loop) is slower and harder to read.

Wrap-up and next steps

Python's exception system rewards a little study. The four-part try statement, an EAFP mindset, well-named custom exceptions, and disciplined chaining will make your errors informative instead of cryptic. The 3.11-era ExceptionGroup and except* extend that model to the increasingly common case of many-at-once failures, especially in concurrent code.

From here, explore contextlib more deeply for custom context managers that clean up on failure, read the traceback module for programmatic access to stack information, and if you write async code, look at how asyncio.TaskGroup uses exception groups in practice. Handle errors deliberately, and your future self — debugging at 2 a.m. — will thank you.