Python Exception Handling Practice: try/except/else/finally, raise from, custom exceptions

When an exception is raised, Python walks up the call stack looking for a matching except clause. If none is found, the program crashes with a traceback.

Your job is to catch exceptions at the right level — the Facade design pattern often serves as that natural boundary, catching low-level errors and exposing a clean, simplified interface to callers:

• Too low: You handle errors before you have enough context to respond properly
• Too high: Errors propagate far from their source, making debugging harder
• Just right: Catch where you can take meaningful action (retry, log, convert, recover)

Python idiomatically prefers EAFP ("Easier to Ask Forgiveness than Permission") over LBYL ("Look Before You Leap").

# LBYL: check first, then act
if key in my_dict:
    value = my_dict[key]
else:
    value = default

# EAFP: try it, handle failure
try:
    value = my_dict[key]
except KeyError:
    value = default

Why prefer EAFP?

1. Avoids race conditions: The file might exist when you check, but be deleted before you open it. try/except handles this atomically.

2. Faster when errors are rare: In Python 3.11+, entering a try block costs essentially nothing. You only pay when an exception is raised.

3. Cleaner code: One path for the common case, explicit handling for the exceptional case.

# LBYL has a race condition:
if os.path.exists(filename):
    # File could be deleted here by another process!
    with open(filename) as f:
        data = f.read()

# EAFP is atomic:
try:
    with open(filename) as f:
        data = f.read()
except FileNotFoundError:
    data = ""

When LBYL is better: When the check is cheap and failure is common (e.g., checking if items: before iterating), or when the "asking forgiveness" has side effects you want to avoid.

Most tutorials show try/except. Here's the complete structure:

try:
    result = risky_operation()  # Only code that might raise
except SpecificError as e:
    handle_error(e)             # Recovery or re-raise
else:
    use_result(result)          # Only runs if no exception
finally:
    cleanup()                   # Always runs

Why else matters: It keeps your try block minimal. Code in else only runs on success, and exceptions there aren't caught by the preceding except. For a printable reference of common patterns, see the Python error handling cheat sheet.

Why finally matters: It runs whether you succeed, fail, or even if you return from inside the try block. Use it for cleanup that must happen.

Rule of thumb: Catch the most specific exception that makes sense. You can always catch multiple:

except (FileNotFoundError, PermissionError) as e:
    ...

When you translate a low-level exception into a domain exception, chain them explicitly:

try:
    data = json.loads(raw)
except json.JSONDecodeError as e:
    raise ConfigError("Invalid config format") from e

The traceback shows both exceptions with "The above exception was the direct cause of the following exception." This makes the causal relationship clear.

Without from, Python still preserves the original via implicit chaining (__context__), but the traceback says "During handling of the above exception, another exception occurred"—which is less clear about intent:

raise ConfigError("Invalid config format")  # __context__ keeps original, but relationship is ambiguous

Using raise ... from e signals that the translation is deliberate.

Suppress chaining explicitly (rare):

raise ConfigError("...") from None  # Hides the original intentionally

Both ensure cleanup happens. Prefer context managers when available:

# Context manager (preferred)
with open("file.txt") as f:
    data = f.read()
# f.close() called automatically

# Equivalent finally block
f = open("file.txt")
try:
    data = f.read()
finally:
    f.close()

Context managers:

• Combine setup and cleanup in one statement
• Work with async with for async code
• Are harder to get wrong (no forgetting the finally)

Use finally for custom cleanup that doesn't fit the context manager pattern.

Create custom exceptions when you need to:

1. Distinguish your errors from built-in ones
2. Add domain-specific information
3. Create a hierarchy for different error types

class AppError(Exception):
    """Base class for application errors."""
    pass

class ConfigError(AppError):
    """Configuration is invalid or missing."""
    pass

class ValidationError(AppError):
    """User input failed validation."""
    def __init__(self, field: str, message: str):
        self.field = field
        super().__init__(f"{field}: {message}")

Now callers can catch AppError for all your errors, or specific subclasses for targeted handling.

Never silently swallow exceptions. At minimum, log them:

import logging

try:
    process(data)
except Exception:
    logging.exception("Processing failed")  # Includes full traceback
    raise  # Re-raise to let caller handle

# Or if you're recovering:
except ValueError as e:
    logging.warning(f"Invalid data, using default: {e}")
    data = default_value

logging.exception() automatically includes the traceback. Use logging.error(..., exc_info=True) if you need more control.

For transient failures (network timeouts, rate limits), retry with exponential backoff:

import time

def fetch_with_retry(url, max_attempts=3):
    for attempt in range(max_attempts):
        try:
            return fetch(url)
        except (ConnectionError, TimeoutError) as e:
            if attempt == max_attempts - 1:
                raise  # Final attempt failed, propagate
            wait = 2 ** attempt  # 1s, 2s, 4s...
            logging.warning(f"Attempt {attempt + 1} failed: {e}. Retrying in {wait}s")
            time.sleep(wait)

Key points:

• Only retry on transient errors (network, rate limits)—not on ValueError or logic errors
• Use exponential backoff to avoid hammering a failing service
• Set a max attempts limit to avoid infinite loops
• Re-raise on final failure so callers know something went wrong

For production code, consider the tenacity library which handles this pattern elegantly. JavaScript handles async errors differently from Python's synchronous try/except — see Python vs JavaScript error handling for the key differences.

For concurrent code that can have multiple failures:

async def fetch_all(urls):
    results, errors = [], []
    async with asyncio.TaskGroup() as tg:
        for url in urls:
            tg.create_task(fetch(url))
    # If any tasks failed, raises ExceptionGroup

try:
    await fetch_all(urls)
except* ConnectionError as eg:
    # eg.exceptions is a tuple of all ConnectionErrors
    for e in eg.exceptions:
        log.warning(f"Connection failed: {e}")
except* ValueError as eg:
    for e in eg.exceptions:
        log.error(f"Invalid response: {e}")

The except* syntax lets you handle different exception types from the group separately. Rust takes a fundamentally different approach with Result types instead of exceptions — see Python vs Rust error handling for the comparison.

1. Catching too broad, too early

# Bad: hides all bugs
try:
    result = complex_operation()
except Exception:
    result = None  # Masks logic errors!

# Better: catch what you expect
try:
    result = complex_operation()
except (ValueError, KeyError) as e:
    logging.warning(f"Expected error: {e}")
    result = None

2. Empty except block

# Bad: silently swallows everything
try:
    send_email()
except:
    pass

# Better: at least log
try:
    send_email()
except Exception as e:
    logging.warning(f"Email failed: {e}")

3. Losing exception context

# Bad: original error lost
except DatabaseError:
    raise AppError("Database failed")

# Good: chain the exception
except DatabaseError as e:
    raise AppError("Database failed") from e

4. Too much in the try block

# Bad: catching errors from process() too
try:
    data = load_file()
    result = process(data)
    save(result)
except FileNotFoundError:
    ...

# Good: only wrap what can raise that error
try:
    data = load_file()
except FileNotFoundError:
    data = {}
result = process(data)  # Errors here propagate normally
save(result)

• Python Tutorial: Errors and Exceptions
• Built-in Exceptions
• PEP 3134 – Exception Chaining
• PEP 654 – Exception Groups
• logging.exception() documentation