Introduction

Python's raise ... from ... syntax lets you create an exception chain on purpose. It is useful when one low-level error happens, but you want to raise a higher-level exception that better matches your application's domain without losing the original cause.

Use raise ... from ... to Preserve the Real Cause

Without from, you can catch one exception and raise another, but the relationship between them is less explicit. With from, Python records the original exception as the direct cause.

1class ConfigError(Exception):
2    pass
3
4
5def load_port(raw_value):
6    try:
7        return int(raw_value)
8    except ValueError as exc:
9        raise ConfigError("PORT must be an integer") from exc
10
11
12load_port("abc")

When this fails, the traceback shows both exceptions and clearly states that the ConfigError was caused by the original ValueError. That is much easier to debug than a generic replacement exception with no chain.

In other words, you are not just raising a new error. You are documenting the causal path from the low-level failure to the higher-level failure that the rest of the application should understand.

Why This Is Better Than Losing Context

Suppose your code reads JSON, validates a field, and exposes a domain-specific API. You usually do not want raw parsing errors to leak directly to every caller, but you also do not want to erase the original failure.

1import json
2
3
4class SettingsError(Exception):
5    pass
6
7
8def parse_settings(text):
9    try:
10        return json.loads(text)
11    except json.JSONDecodeError as exc:
12        raise SettingsError("Invalid settings file") from exc

Now callers see an error name that matches your application, while developers still get the low-level parsing cause in the traceback.

This pattern is especially good at module boundaries:

• parsing and validation layers
• database wrappers
• HTTP client abstractions
• library APIs that hide implementation details

Use from None When You Intentionally Want to Hide Context

Sometimes the original exception is just noise for the caller. Python lets you suppress implicit chaining with from None.

1def get_required(config, key):
2    try:
3        return config[key]
4    except KeyError:
5        raise ValueError(f"Missing required key: {key}") from None

This produces a cleaner traceback by omitting the original KeyError as the visible cause. Use it sparingly. Most of the time, preserving the underlying exception is more helpful.

When to Reach for It

Use raise ... from ... when you are translating errors across abstraction layers. A storage layer might catch OSError and raise RepositoryError. A config loader might catch JSONDecodeError and raise SettingsError. The rule is simple: add domain meaning without discarding diagnostic value.

Avoid using it just to wrap every exception automatically. If the higher-level exception adds no useful information, the extra layer may only make the traceback noisier.

That balance is what makes exception chaining valuable. A good chained exception gives the caller a cleaner API while still giving maintainers the original technical reason the operation failed.

Common Pitfalls

• Raising a new exception without from and accidentally hiding the original cause.
• Over-wrapping exceptions when the new error message adds no meaningful context.
• Using from None too aggressively and making debugging harder than it needs to be.
• Catching overly broad exceptions such as Exception and then chaining them all into one generic error type.

Summary

• 'raise ... from ... links a new exception to the original cause explicitly.'
• It is ideal for translating low-level failures into domain-specific errors.
• The traceback stays informative because Python preserves the cause chain.
• 'from None suppresses the original context when you intentionally want a cleaner error.'
• Use exception chaining to improve clarity, not just to add another layer of abstraction.