Recap — Exceptions, Retries, Result Types

# Exceptions, Retries, Result Types Error handling shapes whether your code is reliable. Production Python has consistent patterns; let's cover them. ## The basics ```python try: risky_operation() except SpecificError as e: handle(e) except (TypeError, ValueError) as e: handle_multiple(e) except Exception as e: log_unexpected(e) raise finally: cleanup() ``` `finally` runs whether exception or not. Use for cleanup that `with` doesn't cover. ## EAFP vs LBYL (Python style) **EAFP**: Easier to Ask Forgiveness than Permission. Try the operation; catch failure. ```python try: value = my_dict[key] except KeyError: value = default ``` **LBYL**: Look Before You Leap. Check before the operation. ```python if key in my_dict: value = my_dict[key] else: value = default ``` Pythonic style favors EAFP for most cases: - Cleaner code (one path, not two). - No race condition (LBYL can fail if state changes between check and use). - Idiomatic. But: when checking is cheap and the failure is common, LBYL is fine. ## Designing exception hierarchies For your library/app, create a hierarchy: ```python class AppError(Exception): # Base for all app errors. pass class UserError(AppError): # User did something wrong. pass class ValidationError(UserError): # Input failed validation. pass class AuthError(UserError): # Authentication failed. pass class ServerError(AppError): # Something went wrong on our end. pass class DatabaseError(ServerError): ... class ExternalServiceError(ServerError): ... ``` Why: - Callers can catch by category (`except UserError` for all user errors). - Specific errors are still distinguishable. - Errors form a graph showing what they mean. ## Adding context to exceptions ```python class UserNotFoundError(AppError): def __init__(self, user_id): self.user_id = user_id super().__init__(f"User {user_id} not found") ``` Include relevant data on the exception. Helps debugging. For HTTP APIs, exceptions can carry status codes: ```python class APIError(AppError): status_code = 500 class NotFoundError(APIError): status_code = 404 ``` ## Re-raising vs swallowing ```python try: operation() except SomeError as e: log(e) raise # re-raise after logging # vs try: operation() except SomeError as e: log(e) # swallow — operation failed, but we continue ``` Don't silently swallow. If you catch, either: - Handle (recover or default). - Re-raise (after logging or transformation). - Wrap with a custom exception (`raise MyError(...) from e`). `raise from e` preserves the cause chain. ## Retries with tenacity For transient errors (network, rate limits), retry with backoff: ```python from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type @retry( stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10), retry=retry_if_exception_type((HTTPError, ConnectionError)), ) def fetch_data(): return requests.get(URL).json() ``` What this does: - Try up to 3 times. - Wait 1s, 2s, 4s, ... (exponential backoff) between attempts. - Retry only on HTTPError or ConnectionError; not on ValueError. ### Adding jitter To avoid thundering herd: ```python from tenacity import wait_exponential_jitter wait=wait_exponential_jitter(initial=1, max=10) ``` Adds random jitter so all clients don't retry at exactly the same time. ### Manual retry pattern ```python import time def fetch_with_retry(url, retries=3): for attempt in range(retries): try: return requests.get(url).json() except (HTTPError, ConnectionError) as e: if attempt == retries - 1: raise time.sleep(2 ** attempt) ``` Tenacity is cleaner; the manual version helps you understand what's happening. ## Result types (functional style) Some teams prefer explicit error returns over exceptions: ```python from typing import Generic, TypeVar from dataclasses import dataclass T = TypeVar("T") E = TypeVar("E") @dataclass class Ok(Generic[T]): value: T @dataclass class Err(Generic[E]): error: E Result = Ok | Err def divide(a: int, b: int) -> Result[float, str]: if b == 0: return Err("division by zero") return Ok(a / b) result = divide(10, 0) match result: case Ok(value): print(value) case Err(error): print(error) ``` Pros: errors are part of the type signature; can't be forgotten. Cons: more verbose than exceptions; not idiomatic Python. Library: `result` (returns library) implements this. When to use: - Domain-specific operations where caller MUST handle the failure case. - Functional code style. For most Python: exceptions are fine. Result types are an option, not the default. ## Don't catch `Exception` (usually) ```python # Bad: catches EVERYTHING try: operation() except Exception: pass ``` This catches: - The actual e