← Python

Error Handling & Exceptions

Pythonic Idioms & Philosophy

← Error Handling & Exceptions

Select a question from the sidebar

12 questions in this topic

Question 1 / 12

How does `try/except/else/finally` work in Python, and what is the execution order?

Python's exception handling has four clauses:

try: The code that might raise an exception
except: Handles specific exceptions if they occur
else: Runs ONLY if no exception was raised in try -- useful for code that should run only on success
finally: ALWAYS runs, whether an exception occurred or not -- used for cleanup

Execution order:

No exception: try -> else -> finally
Exception caught: try (partial) -> except -> finally
Exception not caught: try (partial) -> finally -> exception propagates

The else clause is often overlooked but is important for separating the "protected" code (in try) from the "success path" code (in else). This prevents accidentally catching exceptions from the success code.

The finally clause runs even if there's a return, break, or continue in try or except.

Pseudo Code

try:
    # Code that might raise
except SpecificError as e:
    # Handle the error
else:
    # Only runs if NO exception in try
finally:
    # ALWAYS runs (cleanup)

Execution paths:
  Success: try -> else -> finally
  Caught: try -> except -> finally
  Uncaught: try -> finally -> propagate

Code

# Basic try/except/else/finally
def divide(a, b):
    try:
        result = a / b
    except ZeroDivisionError:
        print("Cannot divide by zero")
        return None
    except TypeError as e:
        print(f"Type error: {e}")
        return None
    else:
        # Only runs if no exception in try
        print(f"{a} / {b} = {result}")
        return result
    finally:
        # Always runs
        print("Division operation complete")

print(divide(10, 3))
# 10 / 3 = 3.3333...
# Division operation complete
# 3.333...

print(divide(10, 0))
# Cannot divide by zero
# Division operation complete
# None

# Why else matters -- separating protected code from success code
def read_config(path):
    try:
        f = open(path)
    except FileNotFoundError:
        print(f"Config not found: {path}")
        return {}
    else:
        # This code is NOT protected by except
        # If json.loads raises, it propagates (which is correct!)
        import json
        data = json.loads(f.read())
        f.close()
        return data

# finally runs even with return
def example():
    try:
        return "from try"
    finally:
        print("finally runs!")

result = example()
# finally runs!
print(result)  # "from try"

# CAUTION: return in finally overrides return in try
def dangerous():
    try:
        return "try value"
    finally:
        return "finally value"  # overrides try's return!

print(dangerous())  # "finally value" -- surprising!

# Multiple except clauses
def process(data):
    try:
        value = int(data)
        result = 100 / value
    except ValueError:
        return "Not a number"
    except ZeroDivisionError:
        return "Cannot be zero"
    except (TypeError, AttributeError) as e:
        return f"Bad input: {e}"
    else:
        return result

10 / 3 = 3.3333333333333335
Division operation complete
3.3333333333333335
Cannot divide by zero
Division operation complete
None
finally runs!
from try
finally value

Key Points

•else runs only if no exception; finally always runs
•Use else to separate protected code from success-path code
•finally runs even with return, break, or continue
•Multiple except clauses handle different exception types

Gotchas

•return in finally overrides return in try or except
•Bare except (except:) catches BaseException including SystemExit and KeyboardInterrupt
•else prevents accidentally catching exceptions from success code
•finally runs even if except re-raises the exception

try runs code, except handles errors, else runs on success only, finally always runs. Use else to keep success code out of the try block.

•Success: try -> else -> finally
•Error: try -> except -> finally

try:
    result = int("42")
except ValueError:
    print("Not a number")
else:
    print(f"Got {result}")  # Got 42 (no exception)
finally:
    print("Done")           # always runs

Got 42
Done

return in finally overrides return in try

Question 2 / 12

How does Python's exception hierarchy work, and why does it matter?

Python's exception hierarchy is a class tree rooted at BaseException:

BaseException
  +-- SystemExit
  +-- KeyboardInterrupt
  +-- GeneratorExit
  +-- Exception
       +-- StopIteration
       +-- ArithmeticError
       |    +-- ZeroDivisionError
       |    +-- OverflowError
       +-- LookupError
       |    +-- IndexError
       |    +-- KeyError
       +-- OSError
       |    +-- FileNotFoundError
       |    +-- PermissionError
       +-- ValueError
       +-- TypeError
       +-- AttributeError
       +-- RuntimeError
       +-- ...

Key distinctions:

BaseException is the root of ALL exceptions
Exception is the root of all "regular" exceptions
SystemExit, KeyboardInterrupt, GeneratorExit inherit from BaseException but NOT Exception

This matters because except Exception catches all regular errors but lets SystemExit (sys.exit), KeyboardInterrupt (Ctrl+C), and GeneratorExit propagate. Never use bare except: or except BaseException as they prevent clean shutdown.

Catching a parent exception also catches all its children. except LookupError catches both IndexError and KeyError.

Pseudo Code

BaseException (root)
  |- SystemExit (sys.exit) -- DON'T catch
  |- KeyboardInterrupt (Ctrl+C) -- DON'T catch
  |- GeneratorExit -- DON'T catch
  |- Exception (catch this for general errors)
       |- ValueError, TypeError, KeyError, etc.

Rules:
1. Catch specific exceptions, not Exception
2. except Exception is OK as a last resort
3. Never catch BaseException or use bare except:

Code

# Exception hierarchy in action
try:
    d = {"a": 1}
    print(d["b"])  # KeyError
except LookupError as e:
    # Catches both KeyError and IndexError
    print(f"Lookup failed: {e}")  # Lookup failed: 'b'

# Catching parent catches children
try:
    1 / 0
except ArithmeticError:  # catches ZeroDivisionError
    print("Math error")

# Why bare except is dangerous
def bad_handler():
    while True:
        try:
            data = input("Enter number: ")
            return int(data)
        except:  # catches KeyboardInterrupt!
            print("Try again")  # Ctrl+C can't exit!

# Correct way
def good_handler():
    while True:
        try:
            data = input("Enter number: ")
            return int(data)
        except ValueError:  # only catch what you expect
            print("Try again")

# Inspecting the hierarchy
print(issubclass(KeyError, LookupError))      # True
print(issubclass(FileNotFoundError, OSError))  # True
print(issubclass(KeyboardInterrupt, Exception))  # False!
print(issubclass(SystemExit, Exception))          # False!

# except Exception is a reasonable catch-all
def safe_process(func, *args):
    try:
        return func(*args)
    except Exception as e:
        # Catches all regular exceptions
        # KeyboardInterrupt and SystemExit still propagate
        print(f"Error: {type(e).__name__}: {e}")
        return None

# Order matters: more specific exceptions first
try:
    raise FileNotFoundError("config.json")
except FileNotFoundError:
    print("File not found")    # This runs
except OSError:
    print("OS error")          # Skipped (more general)
except Exception:
    print("General error")     # Skipped (even more general)

Lookup failed: 'b'
Math error
True
True
False
False
File not found

Key Points

•BaseException is root; Exception is root of 'regular' exceptions
•SystemExit, KeyboardInterrupt are NOT subclasses of Exception
•Catching a parent catches all its children
•Order except clauses from most specific to most general

Gotchas

•Bare except: catches BaseException including KeyboardInterrupt and SystemExit
•except Exception catches almost everything but lets Ctrl+C and sys.exit work
•More specific exceptions must come before general ones or they're unreachable
•Some exceptions have surprising parents: bool is subclass of int, FileNotFoundError of OSError

Exception is the base for regular errors. SystemExit and KeyboardInterrupt are under BaseException but NOT Exception. Catch specific exceptions; except Exception as last resort.

•except Exception catches regular errors, not SystemExit/KeyboardInterrupt
•Catch specific exceptions first, general ones last

# Catching parent catches children
try:
    raise FileNotFoundError("missing.txt")
except OSError as e:  # FileNotFoundError is subclass of OSError
    print(f"OS error: {e}")

# Never use bare except
try:
    pass
except Exception as e:  # OK: lets Ctrl+C and sys.exit propagate
    print(f"Error: {e}")

OS error: missing.txt

Bare except catches BaseException -- prevents Ctrl+C

Question 3 / 12

How do you create custom exceptions in Python?

Custom exceptions should inherit from Exception (or a more specific built-in exception). They allow you to:

Create domain-specific error types
Carry additional context about what went wrong
Enable specific error handling at different layers
Provide clear error hierarchies for your application

Best practices:

Create a base exception for your package/module
Inherit specific exceptions from that base
Add useful attributes (error codes, context data)
Override __str__ for human-readable messages
Keep the hierarchy flat and focused

Pseudo Code

1. class AppError(Exception): -- base for your app
2. class ValidationError(AppError): -- specific error
3. Add __init__ with extra attributes (code, field, etc.)
4. Override __str__ for readable messages
5. Catch with: except ValidationError as e

Code

# Base exception for the application
class AppError(Exception):
    """Base exception for the application."""
    def __init__(self, message, code=None):
        self.message = message
        self.code = code
        super().__init__(message)

    def __str__(self):
        if self.code:
            return f"[{self.code}] {self.message}"
        return self.message

# Specific exceptions
class ValidationError(AppError):
    """Raised when input validation fails."""
    def __init__(self, field, message, value=None):
        self.field = field
        self.value = value
        super().__init__(f"{field}: {message}", code="VALIDATION_ERROR")

class NotFoundError(AppError):
    """Raised when a resource is not found."""
    def __init__(self, resource_type, resource_id):
        self.resource_type = resource_type
        self.resource_id = resource_id
        super().__init__(
            f"{resource_type} with id {resource_id} not found",
            code="NOT_FOUND"
        )

class AuthenticationError(AppError):
    """Raised when authentication fails."""
    def __init__(self, reason="Invalid credentials"):
        super().__init__(reason, code="AUTH_ERROR")

# Usage
def create_user(name, age):
    if not name or not name.strip():
        raise ValidationError("name", "cannot be empty", value=name)
    if not isinstance(age, int) or age < 0 or age > 150:
        raise ValidationError("age", "must be between 0 and 150", value=age)
    return {"name": name, "age": age}

def get_user(user_id):
    users = {1: "Alice", 2: "Bob"}
    if user_id not in users:
        raise NotFoundError("User", user_id)
    return users[user_id]

# Catching specific exceptions
try:
    create_user("", 25)
except ValidationError as e:
    print(e)        # [VALIDATION_ERROR] name: cannot be empty
    print(e.field)  # name
    print(e.value)  # (empty string)

# Catching the base exception catches all app errors
try:
    get_user(999)
except AppError as e:
    print(e)       # [NOT_FOUND] User with id 999 not found
    print(e.code)  # NOT_FOUND

# Exception hierarchy check
print(issubclass(ValidationError, AppError))   # True
print(issubclass(ValidationError, Exception))  # True
print(issubclass(NotFoundError, AppError))     # True

[VALIDATION_ERROR] name: cannot be empty
name

[NOT_FOUND] User with id 999 not found
NOT_FOUND
True
True
True

Key Points

•Inherit from Exception (or specific built-in exception)
•Create a base exception for your application/package
•Add useful attributes (code, field, context)
•Always call super().__init__(message)

Gotchas

•Always inherit from Exception, never from BaseException
•Call super().__init__() to ensure the exception message is set correctly
•Keep exception hierarchies flat -- deep hierarchies are hard to maintain
•Don't use exceptions for flow control -- they're for exceptional conditions

Inherit from Exception, add useful attributes, call super().__init__(). Create a base exception for your app and specific ones inheriting from it.

•Inherit from Exception, add context attributes
•Base exception for the app, specific ones below

class AppError(Exception):
    pass

class NotFoundError(AppError):
    def __init__(self, resource, id):
        self.resource = resource
        self.id = id
        super().__init__(f"{resource} {id} not found")

try:
    raise NotFoundError("User", 42)
except NotFoundError as e:
    print(e)            # User 42 not found
    print(e.resource)   # User

User 42 not found
User

Always call super().__init__() with the message

Question 4 / 12

How does exception chaining work with `raise ... from ...`?

Python supports exception chaining through two mechanisms:

Explicit chaining (raise X from Y): Sets X.__cause__ to Y. Used when you want to show that one exception was directly caused by another. The traceback shows "The above exception was the direct cause..."
Implicit chaining: When an exception is raised inside an except block, Python automatically sets X.__context__ to the original exception. The traceback shows "During handling of the above exception..."
Suppressing context (raise X from None): Hides the implicit chaining. The original exception is not shown in the traceback.

Exception chaining is important for:

Providing clear error causality in logs
Converting low-level exceptions to domain-specific ones without losing context
Debugging complex exception chains

Pseudo Code

Explicit chaining:
  raise NewError('msg') from original_error
  -> NewError.__cause__ = original_error
  -> Traceback: 'direct cause of'

Implicit chaining:
  except SomeError:
      raise NewError('msg')  # auto-sets __context__
  -> Traceback: 'During handling of'

Suppress context:
  raise NewError('msg') from None
  -> Hides the original exception

Code

# Explicit chaining: raise ... from ...
class DatabaseError(Exception):
    pass

def get_user(user_id):
    try:
        # Simulate database error
        raise ConnectionError("Connection refused on port 5432")
    except ConnectionError as e:
        raise DatabaseError(f"Failed to fetch user {user_id}") from e

try:
    get_user(42)
except DatabaseError as e:
    print(f"Error: {e}")              # Failed to fetch user 42
    print(f"Caused by: {e.__cause__}")  # Connection refused on port 5432
    print(f"Type: {type(e.__cause__).__name__}")  # ConnectionError

# Implicit chaining (automatic __context__)
def process():
    try:
        int("not_a_number")
    except ValueError:
        # Raising a new exception inside except auto-sets __context__
        raise RuntimeError("Processing failed")

try:
    process()
except RuntimeError as e:
    print(f"Error: {e}")
    print(f"Context: {e.__context__}")  # invalid literal for int()...

# Suppressing context: raise ... from None
class APIError(Exception):
    pass

def fetch_data():
    try:
        raise ConnectionError("Internal network details")
    except ConnectionError:
        # Hide internal details from API consumers
        raise APIError("Service unavailable") from None

try:
    fetch_data()
except APIError as e:
    print(f"Error: {e}")              # Service unavailable
    print(f"Cause: {e.__cause__}")     # None
    print(f"Context: {e.__context__}")  # None (suppressed)

# Full chain inspection
def full_chain(exc):
    """Walk the exception chain."""
    chain = []
    while exc is not None:
        chain.append(f"{type(exc).__name__}: {exc}")
        exc = exc.__cause__ or exc.__context__
    return chain

try:
    get_user(42)
except DatabaseError as e:
    for item in full_chain(e):
        print(item)
    # DatabaseError: Failed to fetch user 42
    # ConnectionError: Connection refused on port 5432

Error: Failed to fetch user 42
Caused by: Connection refused on port 5432
Type: ConnectionError
Error: Processing failed
Context: invalid literal for int() with base 10: 'not_a_number'
Error: Service unavailable
Cause: None
Context: Internal network details
DatabaseError: Failed to fetch user 42
ConnectionError: Connection refused on port 5432

Key Points

•raise X from Y sets __cause__ (explicit, 'direct cause of')
•Raising in except auto-sets __context__ (implicit, 'during handling of')
•raise X from None suppresses the chain
•__cause__ takes precedence over __context__ in traceback display

Gotchas

•Without 'from', the original exception still shows via implicit chaining (__context__)
•'from None' hides potentially useful debugging information
•__cause__ (explicit) takes display precedence over __context__ (implicit)
•Both __cause__ and __context__ may be set; __cause__ is checked first

raise X from Y chains exceptions explicitly (__cause__). Raising in except auto-chains via __context__. raise X from None suppresses the chain.

•'raise from' for explicit chaining, 'from None' to suppress
•__cause__ for explicit, __context__ for implicit

class AppError(Exception):
    pass

try:
    int("bad")
except ValueError as e:
    raise AppError("Bad input") from e  # explicit chain

# In traceback:
# ValueError: invalid literal...
# The above exception was the direct cause of:
# AppError: Bad input

'from None' hides useful debugging info

Question 5 / 12

What is EAFP vs LBYL, and which approach does Python prefer?

EAFP (Easier to Ask Forgiveness than Permission): Try the operation and handle exceptions if they occur. This is the Pythonic approach.

LBYL (Look Before You Leap): Check preconditions before performing an operation. Common in languages like C and Java.

Python favors EAFP because:

Avoids race conditions: Between checking and acting, the state can change (TOCTOU bugs)
Faster for the common case: If exceptions are rare, try/except is faster than checking every time
Duck typing friendly: Check behavior, not type
Cleaner code: Often results in shorter, more readable code

However, LBYL is appropriate when:

The check is significantly cheaper than the exception
The operation has side effects that can't be undone
Readability is improved by explicit checks

Pseudo Code

LBYL (Look Before You Leap):
  if key in dictionary:
      value = dictionary[key]
  else:
      value = default

EAFP (Ask Forgiveness):
  try:
      value = dictionary[key]
  except KeyError:
      value = default

Python prefers EAFP for most cases

Code

import os

# Example 1: Dictionary access
data = {"name": "Alice", "age": 30}

# LBYL
if "email" in data:
    email = data["email"]
else:
    email = "unknown"

# EAFP (Pythonic)
try:
    email = data["email"]
except KeyError:
    email = "unknown"

# Even better: use dict.get()
email = data.get("email", "unknown")

# Example 2: File operations
path = "/tmp/config.json"

# LBYL -- race condition: file could be deleted between check and open
if os.path.exists(path):
    with open(path) as f:  # might still fail!
        content = f.read()

# EAFP -- no race condition
try:
    with open(path) as f:
        content = f.read()
except FileNotFoundError:
    content = "{}"

# Example 3: Type conversion
user_input = "42"

# LBYL
if user_input.isdigit():
    number = int(user_input)
else:
    number = 0  # but isdigit() doesn't handle negative numbers!

# EAFP (handles all cases)
try:
    number = int(user_input)
except ValueError:
    number = 0

# Example 4: Attribute access (duck typing)
def get_length(obj):
    # LBYL -- checks type, not behavior
    if isinstance(obj, (list, str, tuple)):
        return len(obj)
    return None

    # EAFP -- checks behavior (duck typing)
def get_length_eafp(obj):
    try:
        return len(obj)
    except TypeError:
        return None

# Works with any object that has __len__
print(get_length_eafp([1, 2, 3]))  # 3
print(get_length_eafp("hello"))    # 5
print(get_length_eafp(42))         # None

# When LBYL IS appropriate: expensive operations
def process_file(path):
    # LBYL is OK here: checking is cheap, opening/reading is expensive
    if not os.path.isfile(path):
        raise FileNotFoundError(f"Not a file: {path}")
    if os.path.getsize(path) > 100_000_000:  # 100MB
        raise ValueError(f"File too large: {path}")
    # Now proceed with expensive processing
    with open(path) as f:
        return f.read()

3
5
None

Key Points

•EAFP: try/except -- Pythonic, avoids race conditions, duck-typing friendly
•LBYL: check-then-act -- risk of TOCTOU bugs, slower for common case
•Python favors EAFP for most situations
•Use LBYL when checks are cheap and operations have irreversible side effects

Gotchas

•LBYL file checks have TOCTOU (Time of Check to Time of Use) race conditions
•EAFP is slower when exceptions are frequent (exception handling is expensive)
•LBYL with isinstance checks often fights duck typing
•dict.get() and getattr() with defaults are EAFP patterns without explicit try/except

EAFP: try it, handle exceptions. LBYL: check first. Python prefers EAFP because it avoids race conditions, supports duck typing, and is faster for the common case.

•EAFP is Pythonic -- try first, handle errors
•LBYL has TOCTOU race conditions

# LBYL (not Pythonic)
if "key" in d:
    val = d["key"]

# EAFP (Pythonic)
try:
    val = d["key"]
except KeyError:
    val = default

# Best: built-in EAFP pattern
val = d.get("key", default)

EAFP is slow when exceptions are frequent

Question 6 / 12

How do you re-raise an exception in Python?

There are three ways to re-raise exceptions in Python:

raise (no arguments): Re-raises the current exception with the original traceback intact. This is the most common and preferred way.
raise e (with the caught exception): Re-raises but may alter the traceback. The traceback starts from this raise statement, losing the original location.
raise NewException from e: Raises a new exception chained to the original. Used when converting between exception types.

Always prefer bare raise when you just want to log/inspect an exception and let it propagate. Use raise from when wrapping exceptions in a domain-specific type.

Pseudo Code

1. except as e: raise       -- re-raise with original traceback
2. except as e: raise e     -- re-raise with new traceback point
3. except as e: raise New() from e  -- chain to new exception
4. Always prefer bare 'raise' for pass-through re-raising

Code

import traceback

# 1. Bare raise -- preserves original traceback (preferred)
def process_data(data):
    try:
        result = int(data)
    except ValueError:
        print(f"Warning: invalid data '{data}', re-raising")
        raise  # re-raises ValueError with original traceback

try:
    process_data("not_a_number")
except ValueError as e:
    print(f"Caught: {e}")  # original ValueError

# 2. raise e -- alters traceback (usually not what you want)
def process_data_bad(data):
    try:
        result = int(data)
    except ValueError as e:
        print(f"Warning: {e}")
        raise e  # re-raises but traceback points HERE, not original location

# 3. Conditional re-raising
def safe_divide(a, b):
    try:
        return a / b
    except ZeroDivisionError:
        if b == 0:
            raise  # re-raise for actual zero
        return float('inf')  # handle edge case differently

# 4. Wrap and re-raise with chaining
class ServiceError(Exception):
    pass

def call_api(url):
    try:
        # Simulate various low-level errors
        raise ConnectionError("Connection refused")
    except (ConnectionError, TimeoutError) as e:
        raise ServiceError(f"API call to {url} failed") from e

try:
    call_api("https://api.example.com")
except ServiceError as e:
    print(f"Service error: {e}")
    print(f"Root cause: {e.__cause__}")

# 5. Re-raise after logging
import logging

logger = logging.getLogger(__name__)

def risky_operation():
    try:
        return 1 / 0
    except ZeroDivisionError:
        logger.exception("Division by zero occurred")  # logs with traceback
        raise  # then re-raise

# 6. Pattern: try/except/raise with cleanup
def write_file(path, data):
    f = None
    try:
        f = open(path, 'w')
        f.write(data)
    except IOError:
        print("Write failed, cleaning up")
        raise  # re-raise after cleanup
    finally:
        if f:
            f.close()

Warning: invalid data 'not_a_number', re-raising
Caught: invalid literal for int() with base 10: 'not_a_number'
Service error: API call to https://api.example.com failed
Root cause: Connection refused

Key Points

•Bare 'raise' re-raises with original traceback (preferred)
•'raise e' re-raises but changes the traceback point
•'raise New() from e' wraps in a new exception with chaining
•Use bare raise for logging/inspection then propagation

Gotchas

•'raise e' vs 'raise': the former resets traceback to current line
•bare 'raise' only works inside an except block
•Re-raising after modifying the exception object is OK -- the exception is the same object
•logger.exception() logs the traceback; pair with bare raise

Use bare raise to re-raise with original traceback. Use raise X from e to wrap in a new exception. Bare raise is preferred for logging-then-propagating patterns.

•Bare 'raise' preserves original traceback
•'raise from' for wrapping exceptions

def process(data):
    try:
        return int(data)
    except ValueError:
        print(f"Bad data: {data}")  # log it
        raise  # re-raise with original traceback

try:
    process("bad")
except ValueError as e:
    print(f"Caught: {e}")  # invalid literal for int()...

Bad data: bad
Caught: invalid literal for int() with base 10: 'bad'

'raise e' changes the traceback point -- prefer bare 'raise'

Question 7 / 12

How do context managers help with error handling?

Context managers guarantee cleanup through the with statement, even when exceptions occur. The __exit__ method runs regardless of whether the with block completed successfully or raised an exception.

Context managers solve the problem of resource leaks that occur when exceptions prevent cleanup code from running. Without context managers, you'd need try/finally blocks everywhere.

Key patterns:

Resource management: Files, database connections, network sockets
Exception suppression: contextlib.suppress() as clean alternative to try/except/pass
Temporary state changes: Directory changes, monkey patching, logging levels
Transaction management: Database commits/rollbacks

contextlib provides utilities for creating context managers without writing classes.

Pseudo Code

Context manager guarantees cleanup:
  with resource as r:
      # use r
      # if exception occurs here...
  # __exit__ STILL runs (cleanup guaranteed)

Vs manual approach:
  r = acquire()
  try:
      # use r
  finally:
      release(r)  # must remember this!

Code

from contextlib import contextmanager, suppress
import os

# Context manager for database transactions
class Transaction:
    def __init__(self, conn):
        self.conn = conn

    def __enter__(self):
        self.conn.begin()
        return self.conn

    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type is None:
            self.conn.commit()
        else:
            self.conn.rollback()
        return False  # propagate exceptions

# contextlib.suppress -- clean exception suppression
# Instead of:
try:
    os.remove("/tmp/tempfile")
except FileNotFoundError:
    pass

# Use:
with suppress(FileNotFoundError):
    os.remove("/tmp/tempfile")

# @contextmanager decorator -- simpler than class
@contextmanager
def temporary_directory(path):
    """Context manager that creates and cleans up a temp directory."""
    os.makedirs(path, exist_ok=True)
    try:
        yield path  # value after 'as'
    finally:
        import shutil
        shutil.rmtree(path, ignore_errors=True)

# Usage
with temporary_directory("/tmp/my_work") as d:
    print(f"Working in {d}")
    # Even if this raises, cleanup happens

# Error handling inside context manager
@contextmanager
def error_handler(operation_name):
    try:
        yield
    except Exception as e:
        print(f"Error in {operation_name}: {e}")
        raise  # re-raise after logging

try:
    with error_handler("data processing"):
        result = int("not_a_number")  # logged, then re-raised
except ValueError:
    pass  # re-raised exception caught here

# ExitStack for dynamic context managers
from contextlib import ExitStack

def process_files(paths):
    with ExitStack() as stack:
        files = [stack.enter_context(open(p)) for p in paths]
        # All files guaranteed to be closed, even if one fails
        return [f.read() for f in files]

Working in /tmp/my_work
Error in data processing: invalid literal for int() with base 10: 'not_a_number'

Key Points

•Context managers guarantee cleanup even when exceptions occur
•__exit__ receives exception info and runs regardless
•contextlib.suppress replaces try/except/pass pattern
•@contextmanager simplifies creation with yield-based syntax

Gotchas

•@contextmanager requires exactly one yield; code after yield runs on exit
•ExitStack is needed when the number of context managers is dynamic
•Returning True from __exit__ suppresses the exception -- do this very carefully
•If __enter__ raises, __exit__ is NOT called

Context managers guarantee cleanup via __exit__, even during exceptions. Use contextlib.suppress() for clean exception suppression, @contextmanager for simple creation.

•Guaranteed cleanup even on exceptions
•suppress() replaces try/except/pass

from contextlib import contextmanager, suppress

# Suppress specific exceptions cleanly
with suppress(FileNotFoundError):
    import os
    os.remove("/tmp/nonexistent")

# Simple context manager with decorator
@contextmanager
def timer():
    import time
    start = time.perf_counter()
    yield
    print(f"{time.perf_counter() - start:.4f}s")

with timer():
    sum(range(1_000_000))

0.0068s

@contextmanager needs exactly one yield

Question 8 / 12

How do you properly log exceptions in Python?

Proper exception logging preserves the traceback, uses appropriate log levels, and includes relevant context. Python's logging module provides logger.exception() which automatically includes the traceback.

Key approaches:

logger.exception(msg): Logs at ERROR level with full traceback (only in except block)
logger.error(msg, exc_info=True): Same as above but works anywhere
traceback.format_exc(): Returns traceback as a string for custom handling
traceback.print_exc(): Prints traceback to stderr

Best practices:

Always include the traceback (not just the message)
Log at the right level: ERROR for failures, WARNING for recoverable issues
Add context: what was the operation, what were the inputs
Don't log AND raise (the caller may log too, creating duplicates)

Pseudo Code

1. logger.exception(msg) -- ERROR + traceback (in except block)
2. logger.error(msg, exc_info=True) -- same, works anywhere
3. traceback.format_exc() -- get traceback as string
4. Log at appropriate level, include context
5. Either log OR re-raise, not both (unless top-level handler)

Code

import logging
import traceback

# Setup logging
logging.basicConfig(
    level=logging.DEBUG,
    format="%(asctime)s %(levelname)s %(name)s: %(message)s"
)
logger = logging.getLogger(__name__)

# 1. logger.exception() -- best for most cases
def process_order(order_id):
    try:
        # Simulate error
        raise ValueError(f"Invalid order amount")
    except ValueError:
        logger.exception(f"Failed to process order {order_id}")
        # Logs: ERROR ... Failed to process order 42
        # Traceback (most recent call last):
        #   File ..., line ...
        # ValueError: Invalid order amount

# 2. logger.error with exc_info for conditional logging
def fetch_data(url):
    try:
        raise ConnectionError("Timeout")
    except ConnectionError as e:
        if "timeout" in str(e).lower():
            logger.warning("Timeout fetching %s, will retry", url)
        else:
            logger.error("Failed to fetch %s", url, exc_info=True)
        raise

# 3. traceback.format_exc() for custom handling
def risky_operation():
    try:
        1 / 0
    except ZeroDivisionError:
        tb = traceback.format_exc()
        # Send to monitoring service, save to file, etc.
        print(f"Captured traceback:\n{tb}")

# 4. Structured exception logging
def api_handler(request_data):
    try:
        result = int(request_data["value"])
        return {"result": result}
    except (KeyError, ValueError, TypeError) as e:
        logger.error(
            "API error: type=%s, message=%s, input=%r",
            type(e).__name__,
            str(e),
            request_data,
            exc_info=True
        )
        return {"error": str(e)}

# 5. Anti-pattern: logging AND raising (causes duplicate logs)
def bad_pattern():
    try:
        raise RuntimeError("oops")
    except RuntimeError:
        logger.exception("Error occurred")  # logged here
        raise  # caller will likely log again!

# Better: log at the boundary, raise in intermediate layers
def intermediate_function():
    try:
        raise RuntimeError("oops")
    except RuntimeError:
        raise  # just re-raise, let boundary handle logging

def boundary_handler():
    try:
        intermediate_function()
    except RuntimeError:
        logger.exception("Unhandled error at boundary")  # log once here

Key Points

•logger.exception() logs ERROR + traceback (only in except blocks)
•logger.error(msg, exc_info=True) works anywhere
•Include context: operation name, input data, relevant IDs
•Log at boundaries, raise in intermediate layers

Gotchas

•logger.exception() only works inside except blocks (needs an active exception)
•Logging AND re-raising causes duplicate log entries up the call chain
•Don't log sensitive data (passwords, tokens) in exception messages
•traceback.format_exc() returns empty string if there's no active exception

Use logger.exception() in except blocks for automatic traceback logging. Use exc_info=True parameter for other log levels. Include context, log at boundaries not everywhere.

•logger.exception() for ERROR + traceback
•exc_info=True for other levels

import logging
logger = logging.getLogger(__name__)

try:
    result = 1 / 0
except ZeroDivisionError:
    logger.exception("Division failed")  # ERROR + full traceback
    # Or with different level:
    # logger.warning("Recoverable", exc_info=True)

Don't log AND re-raise -- causes duplicate entries

Question 9 / 12

How does the `warnings` module work, and when should you use it instead of exceptions?

The warnings module issues warning messages without stopping execution. Warnings are for situations that deserve attention but aren't errors:

DeprecationWarning: Feature will be removed in a future version
PendingDeprecationWarning: Feature will be deprecated in the future
RuntimeWarning: Dubious runtime behavior
UserWarning: Default category for user-defined warnings
FutureWarning: Behavior change in a future version

Warnings can be filtered:

'error': Turn warnings into exceptions
'ignore': Suppress warnings
'always': Always show
'default': Show once per location
'module': Show once per module

Use warnings instead of exceptions when the code can still proceed correctly but the developer should be informed of a potential issue.

Pseudo Code

1. warnings.warn(msg, category) -- issue a warning
2. warnings.filterwarnings('error') -- treat as exception
3. warnings.filterwarnings('ignore') -- suppress
4. Use DeprecationWarning for deprecated features
5. stacklevel=2 to show caller's location, not the warning site

Code

import warnings

# Basic warning
def old_function():
    warnings.warn(
        "old_function() is deprecated, use new_function() instead",
        DeprecationWarning,
        stacklevel=2  # shows caller's location, not this line
    )
    return "old result"

# Custom warning category
class PerformanceWarning(UserWarning):
    pass

def process_large_dataset(data):
    if len(data) > 1_000_000:
        warnings.warn(
            f"Processing {len(data)} items may be slow",
            PerformanceWarning,
            stacklevel=2
        )
    return sum(data)

# Calling deprecated function
result = old_function()  # shows warning but continues
print(result)  # "old result"

# Filtering warnings
warnings.filterwarnings("ignore", category=DeprecationWarning)
old_function()  # no warning shown

warnings.filterwarnings("error", category=DeprecationWarning)
try:
    old_function()  # raises DeprecationWarning as exception
except DeprecationWarning as e:
    print(f"Caught: {e}")

# Reset to default
warnings.resetwarnings()

# Context manager for temporary filter
with warnings.catch_warnings():
    warnings.simplefilter("ignore")
    old_function()  # suppressed within this block

# pytest captures warnings
# import pytest
# def test_deprecation():
#     with pytest.warns(DeprecationWarning):
#         old_function()

# When to use warnings vs exceptions:
# Warnings: deprecated code, performance hints, non-critical issues
# Exceptions: errors that prevent correct operation

# Real-world pattern: gradual deprecation
def api_function(param, old_param=None):
    if old_param is not None:
        warnings.warn(
            "old_param is deprecated, use param instead. "
            "old_param will be removed in v3.0",
            DeprecationWarning,
            stacklevel=2
        )
        if param is None:
            param = old_param
    return param

old result
Caught: old_function() is deprecated, use new_function() instead

Key Points

•Warnings inform without stopping execution
•Use DeprecationWarning for deprecated features
•stacklevel=2 shows the caller's location in the warning
•filterwarnings controls visibility: 'error', 'ignore', 'always'

Gotchas

•By default, warnings are shown only once per location
•DeprecationWarning is ignored by default in production; visible in test frameworks
•stacklevel must be correct or the warning points to the wrong line
•warnings.warn() in a loop may show only the first occurrence (use 'always' filter)

Use warnings.warn() for non-fatal issues (deprecation, performance hints). Warnings don't stop execution. Use stacklevel=2 to show caller's location.

•Warnings inform without stopping execution
•stacklevel=2 shows caller's line number

import warnings

def old_api():
    warnings.warn(
        "old_api() is deprecated, use new_api()",
        DeprecationWarning,
        stacklevel=2
    )
    return "result"

result = old_api()  # shows warning, continues running

# Turn warnings into errors for testing
warnings.filterwarnings("error", category=DeprecationWarning)

DeprecationWarning is hidden by default in production

Question 10 / 12

What is the `assert` statement, and when should (and shouldn't) you use it?

assert expression, message raises AssertionError if the expression is falsy. It's a debugging tool for catching programmer errors (bugs), not for handling user input or runtime errors.

Important: Assertions are removed when Python runs with optimization (python -O or PYTHONOPTIMIZE=1). This means:

NEVER use assert for input validation
NEVER use assert for security checks
NEVER use assert for anything that must run in production

Use assert for:

Checking invariants during development
Documenting assumptions in code
Defensive programming against impossible states
Test assertions (pytest uses assert extensively)

assert x, msg is equivalent to if __debug__: if not x: raise AssertionError(msg).

Pseudo Code

assert expression, message

Equivalent to:
if __debug__:
    if not expression:
        raise AssertionError(message)

__debug__ is True normally, False with python -O

DO use for: invariants, assumptions, tests
DON'T use for: input validation, security, production checks

Code

# Good uses of assert
def calculate_average(numbers):
    assert len(numbers) > 0, "numbers list must not be empty"
    return sum(numbers) / len(numbers)

# Checking invariants
def process_sorted_data(data):
    assert data == sorted(data), "data must be sorted"
    # Binary search or other algorithm that requires sorted input
    return data[len(data) // 2]

# Documenting impossible states
def get_direction(angle):
    angle = angle % 360
    if 0 <= angle < 90:
        return "NE"
    elif 90 <= angle < 180:
        return "SE"
    elif 180 <= angle < 270:
        return "SW"
    elif 270 <= angle < 360:
        return "NW"
    else:
        assert False, f"Unreachable: angle={angle}"  # should never happen

# BAD: assert for input validation (removed with -O!)
def bad_withdraw(account, amount):
    assert amount > 0, "Amount must be positive"  # WRONG!
    # With python -O, this check is removed!
    account.balance -= amount

# GOOD: raise ValueError for input validation
def good_withdraw(account, amount):
    if amount <= 0:
        raise ValueError("Amount must be positive")  # always checked
    account.balance -= amount

# BAD: assert for security
def bad_check_access(user):
    assert user.is_admin, "Admin access required"  # WRONG!
    # Bypassed with python -O!

# GOOD: raise for security
def good_check_access(user):
    if not user.is_admin:
        raise PermissionError("Admin access required")  # always checked

# Assert with tuples -- common gotcha
assert (1 == 2, "This should fail")  # WARNING: always True!
# A non-empty tuple is truthy! The assert passes!
# Correct:
assert 1 == 2, "This should fail"  # AssertionError: This should fail

# In pytest, assert is the primary testing mechanism
def test_addition():
    assert 1 + 1 == 2
    assert isinstance("hello", str)
    assert [1, 2, 3] == [1, 2, 3]

Key Points

•assert is for debugging/development, not production validation
•Removed by python -O optimization flag
•Use for invariants, assumptions, and test assertions
•Use raise ValueError/TypeError for input validation

Gotchas

•assert (expr, msg) is always True because non-empty tuples are truthy -- don't use parentheses
•Assertions are stripped with -O flag -- never use for security or validation
•assert is not a function -- assert(False) works but assert(False, 'msg') is always True
•pytest rewrites assert statements to provide detailed failure messages

assert checks invariants during development. Removed with python -O. Never use for input validation or security. Use raise ValueError/TypeError instead for production checks.

•For development invariants, not production validation
•Removed with python -O

# Good: checking developer assumptions
def binary_search(sorted_list, target):
    assert sorted_list == sorted(sorted_list), "Must be sorted"
    # ... search logic

# Bad: input validation (removed with -O)
# assert amount > 0  # WRONG
if amount <= 0:
    raise ValueError("Amount must be positive")  # CORRECT

assert(expr, msg) is always True -- non-empty tuple

Question 11 / 12

How do you handle multiple exceptions and use exception groups (Python 3.11+)?

Python provides several ways to handle multiple exceptions:

Multiple except clauses: Handle different exceptions differently
Tuple in except: except (TypeError, ValueError) handles both the same way
Exception groups (Python 3.11+): ExceptionGroup bundles multiple exceptions that occurred concurrently
except* (Python 3.11+): Pattern-matching syntax for exception groups

Exception groups are designed for concurrent/async code where multiple independent operations can fail simultaneously. Before 3.11, you could only raise one exception at a time.

except* handles subgroups of an ExceptionGroup, allowing different handlers for different exception types within the same group.

Pseudo Code

Multiple except:
  except TypeError: handle type error
  except ValueError: handle value error

Tuple except:
  except (TypeError, ValueError) as e: handle both

Exception groups (3.11+):
  raise ExceptionGroup('msg', [Error1(), Error2()])
  except* TypeError as eg: handle TypeError subgroup
  except* ValueError as eg: handle ValueError subgroup

Code

# 1. Multiple except clauses
def convert(value, target_type):
    try:
        if target_type == "int":
            return int(value)
        elif target_type == "float":
            return float(value)
        else:
            raise ValueError(f"Unknown type: {target_type}")
    except ValueError as e:
        print(f"Value error: {e}")
        return None
    except TypeError as e:
        print(f"Type error: {e}")
        return None

# 2. Tuple for same handling
def safe_convert(value):
    try:
        return int(value)
    except (ValueError, TypeError) as e:
        print(f"Conversion failed: {type(e).__name__}: {e}")
        return None

print(safe_convert("42"))     # 42
print(safe_convert("hello"))  # Conversion failed: ValueError: ...
print(safe_convert(None))     # Conversion failed: TypeError: ...

# 3. Exception groups (Python 3.11+)
# Simulating concurrent failures
def validate_fields(data):
    errors = []
    if not data.get("name"):
        errors.append(ValueError("name is required"))
    if not isinstance(data.get("age"), int):
        errors.append(TypeError("age must be an integer"))
    if data.get("age", 0) < 0:
        errors.append(ValueError("age must be non-negative"))
    if errors:
        raise ExceptionGroup("Validation failed", errors)
    return data

# Handling exception groups with except*
try:
    validate_fields({"name": "", "age": "not_int"})
except* ValueError as eg:
    print(f"Value errors ({len(eg.exceptions)}):")
    for e in eg.exceptions:
        print(f"  - {e}")
except* TypeError as eg:
    print(f"Type errors ({len(eg.exceptions)}):")
    for e in eg.exceptions:
        print(f"  - {e}")

# Output:
# Value errors (1):
#   - name is required
# Type errors (1):
#   - age must be an integer

# Both except* handlers can run (unlike regular except)
# because ExceptionGroup can contain multiple types

# For Python < 3.11, collect errors manually
def validate_all(data):
    errors = []
    try:
        int(data["age"])
    except (ValueError, KeyError) as e:
        errors.append(str(e))
    try:
        assert data.get("name"), "name required"
    except AssertionError as e:
        errors.append(str(e))
    if errors:
        raise ValueError(f"Validation errors: {'; '.join(errors)}")

42
Conversion failed: ValueError: invalid literal for int() with base 10: 'hello'
None
Conversion failed: TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'
None
Type errors (1):
- '<' not supported between instances of 'str' and 'int'

Key Points

•Tuple syntax handles multiple exceptions the same way
•ExceptionGroup (3.11+) bundles concurrent exceptions
•except* handles subgroups of an ExceptionGroup
•Multiple except* handlers can run for the same ExceptionGroup

Gotchas

•except* is only for ExceptionGroup, not regular exceptions
•ExceptionGroup and except* require Python 3.11+
•Cannot mix except and except* in the same try block
•except* may run multiple handlers (unlike regular except which runs only one)

Handle multiple exceptions with tuples except (A, B) or separate clauses. Python 3.11+ adds ExceptionGroup for concurrent errors and except* for pattern matching.

•Tuple: except (A, B) for same handling
•ExceptionGroup + except* for concurrent errors (3.11+)

# Same handling for multiple types
try:
    result = int("bad")
except (ValueError, TypeError) as e:
    print(f"Error: {e}")

# Python 3.11+ exception groups
try:
    raise ExceptionGroup("errors", [ValueError("bad"), TypeError("wrong")])
except* ValueError as eg:
    print(f"Value errors: {eg.exceptions}")
except* TypeError as eg:
    print(f"Type errors: {eg.exceptions}")

Error: invalid literal for int() with base 10: 'bad'
Value errors: (ValueError('bad'),)
Type errors: (TypeError('wrong'),)

Cannot mix except and except* in same try

Question 12 / 12

What are the best practices for exception handling in Python?

Exception handling best practices ensure robust, maintainable code:

Catch specific exceptions: Never use bare except:. Be as specific as possible.
Don't suppress silently: except: pass hides bugs. At minimum, log the error.
Use else clause: Separate protected code (try) from success path (else).
Use context managers: For resource cleanup instead of try/finally.
Create exception hierarchies: Base exception per package with specific subclasses.
Include context: Error messages should explain what happened and what to do.
Re-raise correctly: Use bare raise to preserve traceback.
EAFP over LBYL: Try the operation, catch the exception.
Don't use exceptions for flow control: Exceptions are for exceptional conditions.
Log at boundaries: Log once at the outermost handler, not at every layer.

Pseudo Code

DO:
  - Catch specific exceptions
  - Use else and finally
  - Create domain-specific exceptions
  - Include helpful error messages
  - Log at boundaries

DON'T:
  - Use bare except or except Exception blindly
  - Silently suppress (except: pass)
  - Use exceptions for normal flow control
  - Log at every level (duplicates)
  - Catch and re-raise without adding value

Code

import logging

logger = logging.getLogger(__name__)

# BAD practices
def bad_example():
    try:
        data = get_data()
    except:  # BAD: bare except
        pass  # BAD: silent suppression

    try:
        result = process(data)  # BAD: data might not be defined!
    except Exception as e:  # BAD: too broad
        print("Error")  # BAD: no context
        raise e  # BAD: lose traceback (should be bare raise)

# GOOD practices
def good_example(user_id: int) -> dict:
    """Fetch and process user data."""
    try:
        raw_data = fetch_user(user_id)
    except ConnectionError:
        logger.warning("Connection failed for user %s, using cache", user_id)
        raw_data = get_cached_user(user_id)
    except TimeoutError:
        raise ServiceUnavailableError("User service timeout") from None
    else:
        # Only runs if fetch succeeded -- not covered by except
        cache_user(user_id, raw_data)

    return transform_user(raw_data)

# Good: specific exceptions with context
class UserNotFoundError(Exception):
    def __init__(self, user_id):
        self.user_id = user_id
        super().__init__(f"User {user_id} not found")

def get_user(user_id: int) -> dict:
    user = db.query("SELECT * FROM users WHERE id = %s", user_id)
    if user is None:
        raise UserNotFoundError(user_id)
    return user

# Good: cleanup with context manager
def process_file(path: str) -> str:
    with open(path) as f:  # auto-cleanup
        return f.read().upper()

# Good: exception boundary pattern
def api_endpoint(request):
    """Top-level handler logs and converts to API response."""
    try:
        result = handle_request(request)
        return {"data": result, "status": 200}
    except ValidationError as e:
        return {"error": str(e), "status": 400}
    except NotFoundError as e:
        return {"error": str(e), "status": 404}
    except Exception:
        logger.exception("Unhandled error in API")  # log once here
        return {"error": "Internal server error", "status": 500}

# Good: multiple operations with proper error handling
def transfer_funds(from_id, to_id, amount):
    if amount <= 0:
        raise ValueError("Transfer amount must be positive")

    try:
        sender = get_account(from_id)
        receiver = get_account(to_id)
    except AccountNotFoundError:
        raise  # let it propagate with original traceback

    if sender.balance < amount:
        raise InsufficientFundsError(from_id, amount, sender.balance)

    with Transaction() as txn:  # context manager for atomicity
        sender.balance -= amount
        receiver.balance += amount

Key Points

•Catch specific exceptions, never bare except
•Use else for success path, context managers for cleanup
•Include helpful context in error messages
•Log at boundaries, not at every layer

Gotchas

•except: pass hides bugs silently -- at minimum log the error
•Catching too broadly (except Exception) can mask programming errors
•Logging at every level creates duplicate log entries
•Don't use exceptions as return values or for normal control flow

Catch specific exceptions, use else for success code, context managers for cleanup. Never bare except: or silent pass. Log at boundaries, include context in messages.

•Specific exceptions, else clause, context managers
•Log at boundaries, include context

# Good pattern: specific exceptions, else, context
def read_config(path):
    try:
        f = open(path)
    except FileNotFoundError:
        return {}  # specific exception, meaningful default
    else:
        import json
        data = json.load(f)  # NOT in try block
        f.close()
        return data

except: pass hides bugs -- always log or handle

Built by onllm.dev

Home GitHub Support awesomePrep