Python Programming / Python Errors and Exceptions

raise and Custom Exceptions

Raise exceptions intentionally, create your own exception classes, and design safe error messages.

1 min readupdated 6 Oct 2026

diagram raise from, bare raise, and raise from None mermaid

  flowchart TD
  A["inside except ZeroDivisionError"] --> B{"how do you raise?"}
  B -->|"raise ValueError(...) from e"| C["__cause__ = the original"]
  C --> D["traceback: 'The above exception was the direct cause'"]
  B -->|"raise ValueError(...)"| E["__cause__ = None, __context__ = the original"]
  E --> F["traceback: 'During handling ... another exception occurred'"]
  B -->|"raise ValueError(...) from None"| G["__cause__ = None, display suppressed"]
  G --> H["the original is hidden from the traceback"]
  H --> I["__context__ is STILL set -- hidden, not erased"]

Raising inside an except block always records what you were handling, so the original error is never lost by accident. The three forms differ in what the traceback claims about the relationship: a deliberate cause, an incidental one, or none shown at all. Choosing wrongly either hides a root cause or blames the wrong thing.

What each form actually sets — verified

Wrapping a ZeroDivisionError in a ValueError:

Form	`__cause__`	`__context__`
`raise ValueError(...) from e`	`ZeroDivisionError`	`ZeroDivisionError`
`raise ValueError(...)`	`None`	`ZeroDivisionError`
`raise ValueError(...) from None`	`None`	`ZeroDivisionError`

The last row is the one worth noticing. from None does not erase the original — it only stops the traceback printing it. The exception object is still reachable through __context__, so a logger that walks the chain can still find it.

Which to use: from e when the original explains the new one — a library error wrapped in your own type. Bare raise when the two are unrelated and you want both visible. from None only when the original is genuinely noise, such as a lookup you deliberately tried and expected to fail.

Why raise exceptions?

You can use raise to:

validate function inputs
enforce rules
stop invalid workflows early

Python

def set_age(age: int) -> int:
    if age < 0:
        raise ValueError("age must be >= 0")
    return age
 
print(set_age(10))
# print(set_age(-1))

Raise with a custom message

Python

score = -5
if score < 0:
    raise ValueError(f"score must be non-negative, got {score}")

Creating custom exceptions

Custom exceptions help you represent domain-specific errors.

Python

class PaymentError(Exception):
    """Raised when a payment fails."""
 
 
def charge(amount: float) -> None:
    if amount <= 0:
        raise PaymentError("Amount must be positive")
 
 
try:
    charge(0)
except PaymentError as e:
    print("Payment failed:", e)

Re-raising exceptions

Sometimes you want to log something and re-raise.

Python

try:
    int("abc")
except ValueError as e:
    print("Logging error:", e)
    raise

Best practices

Don’t leak secrets in error messages.
Use clear messages: what went wrong + what to do.
Prefer built-in exception types when they fit.

sketch Three ways to raise inside an except block p5.js

Raising while handling always records what you were handling, so the original is never lost by accident. The three forms differ in what the traceback claims about the relationship -- a deliberate cause, an incidental one, or none displayed. The last row is the one people get wrong: from None hides the original, it does not erase it.

Check yourself

quizCheck yourself

Inside an `except`, you write `raise ValueError(...) from e`. What is set?
Show answer
C — Both `__cause__` and `__context__` — Verified. `from e` sets `__cause__` explicitly, and `__context__` is set automatically because you were handling something at the time.
What does `raise ... from None` actually do?
Show answer
B — Suppresses its DISPLAY; `__context__` is still set — Verified: `__cause__` is None but `__context__` still holds the original. Anything walking the chain programmatically can still reach it.
A traceback says 'During handling of the above exception, another exception occurred'. What does that indicate?
Show answer
B — Implicit chaining — a bare `raise` inside an `except` — That wording comes from `__context__`. 'The above exception was the direct cause' is the other one, produced by `raise ... from`.
When should you wrap a library exception in your own type with `from e`?
Show answer
B — When the original explains the new one and callers should not depend on the library's type — Wrapping gives callers a stable exception type to catch, and `from e` keeps the root cause in the traceback so debugging is not made harder.

🧪 Try It Yourself

Exercise 1 – Raise a Built-in Exception

exerciseYour turn

script.py

Output

Press Run to see what your code prints.

Exercise 2 – Define a Custom Exception

exerciseYour turn

script.py

Output

Press Run to see what your code prints.

Exercise 3 – Re-raise an Exception

exerciseYour turn

script.py

Output

Press Run to see what your code prints.

raise and Custom Exceptions

Why raise exceptions?

Raise with a custom message

Creating custom exceptions

Re-raising exceptions

Best practices

Check yourself

🧪 Try It Yourself

Exercise 1 – Raise a Built-in Exception

Exercise 2 – Define a Custom Exception

Exercise 3 – Re-raise an Exception

Was this page helpful?