raise and Custom Exceptions

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

raise_example.py

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

raise_message.py

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.

custom_exception.py

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.

reraise.py

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 Pause Restart

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

pch.quizTag pch.quizDefaultTitle

1. Inside an `except`, you write `raise ValueError(...) from e`. What is set?

   A `__cause__` only B `__context__` only C Both `__cause__` and `__context__` D Neither
   pch.quizShowAnswer

   C — Both `__cause__` and `__context__` — Verified. `from e` sets `__cause__` explicitly, and `__context__` is set automatically because you were handling something at the time.

2. What does `raise ... from None` actually do?

   A Erases the original exception B Suppresses its DISPLAY; `__context__` is still set C Re-raises the original D Converts it to a warning
   pch.quizShowAnswer

   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.

3. A traceback says 'During handling of the above exception, another exception occurred'. What does that indicate?

   A Deliberate chaining with `from` B Implicit chaining — a bare `raise` inside an `except` C Two unrelated threads failed D A bug in the interpreter
   pch.quizShowAnswer

   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`.

4. When should you wrap a library exception in your own type with `from e`?

   A Always B When the original explains the new one and callers should not depend on the library's type C Never — it hides information D Only for built-in exceptions
   pch.quizShowAnswer

   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

pch.exerciseTag pch.exerciseTitle

Exercise 2 – Define a Custom Exception

pch.exerciseTag pch.exerciseTitle

Exercise 3 – Re-raise an Exception

pch.exerciseTag pch.exerciseTitle