Python Try-Except-Finally — Silent NameError Leaks

Every program that talks to the outside world — reading files, calling APIs, querying databases — is living dangerously. Files get deleted, networks go down, users type nonsense into forms. Without a plan for those moments, your entire application crashes and takes the user's work down with it. Python's try-except-finally block is that plan. It's the difference between a program that dies with a red traceback and one that recovers gracefully, logs the problem, and keeps running.

The problem it solves is deceptively simple: Python raises an Exception object the instant something goes wrong. If nothing catches it, the interpreter unwinds the entire call stack and halts execution. For a throwaway script that might be acceptable, but in a web server, a data pipeline, or a CLI tool a single unhandled exception can silently corrupt data or permanently lock a resource — a database connection, an open file handle, a network socket — that nothing can reclaim until the process restarts.

try-except-finally gives you a structured way to catch those exceptions at precisely the right layer, respond intelligently, and guarantee cleanup code always runs. By the end of this article you'll understand not just the syntax but when to catch specific exceptions versus broad ones, why the else block exists separately from try, how to avoid the two most dangerous beginner patterns (swallowing errors silently and catching everything), and how to structure exception handling the way it actually looks in production-grade codebases. You'll also have ready-made answers for the interview questions this topic reliably generates.

The Anatomy of try-except-finally: What Each Block Actually Does

Python gives you four distinct blocks you can combine around risky code: try, except, else, and finally. Most tutorials explain what they are. This section focuses on why they're separated — because each boundary is a deliberate design decision that prevents a specific category of bug.

try holds only the code that might fail. The discipline here matters more than it looks: the wider your try block, the harder it becomes to know which line actually raised the exception. Keep it to one logical operation.

except catches a specific exception type and lets you respond to a specific failure mode. You can stack multiple except clauses for different exception classes. Catching broad Exception is sometimes the right call, but it should always be a deliberate choice, not a lazy one.

else runs only when try completes without raising any exception. This block is chronically underused and it solves a real problem. If you put post-success processing inside the try block, any exception it raises will be caught by your own except handlers — masking a completely different bug as if it were the original risky operation failing. Moving that logic into else means only the one risky line lives in try, and exceptions from processing surface cleanly as new, unrelated errors. The else block is essentially a contract: 'this code only runs when the thing above succeeded.'

finally runs unconditionally — success, failure, even if you hit a return statement or re-raise an exception inside except. It exists purely for cleanup: closing file handles, releasing locks, disconnecting from external resources. The Python runtime guarantees it runs before anything else — including call stack unwinding for a re-raised exception.

One important nuance that trips people up: if finally itself raises an exception, that new exception becomes the active one and permanently discards whatever was originally in flight. This is why cleanup code in finally must be robust — guard every resource access, and if you log inside finally, make sure the logger can't itself throw.

import os

def read_user_config(filepath: str) -> dict:
    """
    Reads a key=value config file and returns it as a dict.
    Demonstrates the purpose of each exception handling block.
    """
    config_file = None  # Always initialise before try — see finally guard below
    try:
        # Narrow try: only the single risky IO operation lives here
        config_file = open(filepath, 'r', encoding='utf-8')
        raw_contents = config_file.read()
    except FileNotFoundError:
        # We can handle this meaningfully: return a safe default
        print(f"[CONFIG] {filepath} not found. Returning defaults.")
        return {}
    except PermissionError:
        # We can handle this meaningfully too: tell the caller why
        print(f"[CONFIG] Permission denied for {filepath}. Returning defaults.")
        return {}
    else:
        # else only runs when try succeeded — processing lives here, not in try.
        # Why? If this parsing logic raises an exception, it won't be caught by
        # the FileNotFoundError or PermissionError handlers above — it surfaces
        # cleanly as an unhandled error, which is exactly what we want.
        parsed = {}
        for line in raw_contents.splitlines():
            if '=' in line and not line.startswith('#'):
                key, value = line.split('=', 1)
                parsed[key.strip()] = value.strip()
        return parsed
    finally:
        # finally always runs — success, exception, or early return.
        # The 'is not None' guard prevents NameError if open() itself failed.
        if config_file is not None:
            config_file.close()
            print("[CONFIG] Cleanup: file handle closed.")


if __name__ == '__main__':
    # Scenario 1: valid config file exists
    # Expected: file is read, parsed, handle closed
    print("=== Scenario: Valid file ===")
    result = read_user_config('sample.cfg')
    print(f"Result: {result}")

    # Scenario 2: file does not exist
    # Expected: FileNotFoundError caught, defaults returned, no handle to close
    print("\n=== Scenario: Missing file ===")
    result = read_user_config('missing.cfg')
    print(f"Result: {result}")

Why finally Exists — And Why You Cannot Fake It With Code After the Block

A common instinct when first learning exception handling is to put cleanup code after the try-except block. It looks equivalent. It isn't — and the gap between the two is exactly where production incidents happen.

Picture a database connection. You open it in try, run a query, and an exception fires. Your except block re-raises. Execution never reaches the line below the try-except — the connection leaks. Over time the pool exhausts itself, and at 3am a pager goes off.

finally solves this because Python guarantees it runs before the interpreter does anything else — including unwinding the call stack for a re-raised exception, executing a return statement, or responding to a break or continue inside a loop. 'After the block' gives you none of those guarantees.

There is one important caveat that trips even experienced engineers: if the finally block itself raises an exception, that new exception becomes the active one and the original exception is gone. A NameError on a variable you forgot to initialise, a failed logging call, a second network error during cleanup — any of these inside finally will silently discard the exception you actually cared about. This is not theoretical; it's the root cause of a class of production bugs where error logs go mysteriously silent.

The defensive pattern is always: initialise your resource variable to None before the try block, then guard every usage in finally with an explicit 'if resource is not None' check. Better still, use a context manager — the with statement automates exactly this pattern without the risk.

finally is the right place for exactly three categories of logic: closing file handles and sockets, releasing locks, and resetting shared state. It is never the right place to return a value or to make a decision about the application's control flow.

import sqlite3

def fetch_active_users(db_path: str) -> list:
    """
    Fetches usernames from the database.
    Demonstrates safe resource cleanup with finally and the None-guard pattern.
    """
    connection = None  # Guard: if connect() raises, 'connection' is still defined
    try:
        print("[DB] Opening connection...")
        connection = sqlite3.connect(db_path)
        cursor = connection.cursor()
        cursor.execute("SELECT username FROM users")
        return cursor.fetchall()
    except sqlite3.OperationalError as e:
        # We can add context and re-raise — caller decides what to do
        print(f"[DB] Query failed: {e}")
        raise
    finally:
        # Runs whether the query succeeded, failed, or we hit the return above.
        # The 'is not None' check prevents AttributeError if connect() itself raised.
        if connection is not None:
            connection.close()
            print("[DB] Connection closed.")


# The context manager version — preferred in real codebases
# sqlite3.connect() returns a context manager that auto-commits or rolls back
# and closes the connection, with no manual finally required.
def fetch_active_users_clean(db_path: str) -> list:
    """
    Same logic using a context manager.
    The 'with' statement is try-finally under the hood — __exit__ is always called.
    """
    with sqlite3.connect(db_path) as connection:
        cursor = connection.cursor()
        cursor.execute("SELECT username FROM users")
        return cursor.fetchall()


if __name__ == '__main__':
    print("=== Manual try-finally ===")
    try:
        users = fetch_active_users('app.db')
        print(f"Users: {users}")
    except sqlite3.OperationalError:
        print("Could not retrieve users.")

    print("\n=== Context manager version ===")
    with sqlite3.connect('app.db') as conn:
        rows = conn.execute("SELECT username FROM users").fetchall()
        print(f"Users: {rows}")

Context Managers: The Right Way to Replace Manual try-finally

Once you understand why finally exists, you'll immediately see what context managers are: a protocol that automates the try-finally pattern and makes it impossible to forget. Every time you write 'with open(path) as f:', Python is calling __enter__ at the start and guaranteeing __exit__ is called at the end — regardless of exceptions. That's literally the with statement's entire job.

Why does this matter beyond convenience? Because manual try-finally has two failure modes that context managers eliminate by design. First, you might forget to write the finally block at all. Second, even if you write it, a NameError on an uninitialised variable inside finally can discard the original exception — as shown in the production incident above. A context manager's __exit__ receives the exception as an argument, so it always has something to work with.

Building your own context manager is straightforward. You either implement __enter__ and __exit__ on a class, or use the contextlib.contextmanager decorator on a generator function. The generator approach is usually cleaner for simple cases.

The rule of thumb used in most production codebases: if you find yourself writing try...finally for resource management, ask whether a context manager already exists for that resource. For files, sockets, locks, database connections, and HTTP sessions, they almost always do. Write manual try-finally only when a context manager genuinely doesn't exist or when the cleanup logic is too complex for the protocol.

import contextlib
import sqlite3
import time

# Pattern 1: Class-based context manager
# Use this when you need fine-grained control or stateful cleanup logic.
class TimedOperation:
    """
    Context manager that measures and logs the duration of a block.
    __enter__ runs at the start; __exit__ is guaranteed to run at the end.
    """
    def __init__(self

Real-World Patterns: How Senior Devs Actually Structure Exception Handling

There's a meaningful gap between exception handling that passes code review and exception handling that holds up at 2am under production load. Senior engineers follow a small set of consistent patterns that beginners skip because the reasoning isn't obvious until you've been burned.

Pattern 1 — Catch specific, re-raise general. Catch the exceptions you can actually handle meaningfully at the current layer. If you can't retry it, log extra context, or provide a safe fallback, let it bubble up to someone who can.

Pattern 2 — Log at the boundary. Log an exception exactly once: at the layer where you decide not to re-raise it. Logging at every layer produces duplicate log lines and makes it harder to find the actual decision point during an incident.

Pattern 3 — Custom exceptions carry context. Define your own exception classes for domain-level errors. A raised ApiRequestError(status=429, retry_after=30) gives the caller concrete information to act on. A generic RuntimeError('API failed') gives them nothing.

Pattern 4 — Chain exceptions with raise X from Y. When you catch a low-level exception and raise a higher-level one, always chain them. This preserves the original traceback as __cause__ on the new exception. Without it, the root cause is gone and the next engineer will spend an hour reconstructing it.

Pattern 5 — Exception groups for concurrent work (Python 3.11+). When you run multiple tasks concurrently — via asyncio.gather or a ThreadPoolExecutor — multiple exceptions can fire simultaneously. Python 3.11 introduced ExceptionGroup and the except* syntax specifically for this case. It lets you handle different exception types from a group independently rather than forcing you to pick one.

import urllib.request
import urllib.error
import time
import logging

logger = logging.getLogger("io.thecodeforge.api")


# Pattern 3: Custom exception with domain context
class ApiRequestError(Exception):
    """
    Raised when an API call fails in a way the caller can respond to.
    Carries structured data — not just a message string.
    """
    def __init__(self

Custom Exception Classes: How to Extend the Built-in Hierarchy

Python's built-in exceptions (ValueError, TypeError, RuntimeError) cover a wide range, but in a real application they lack domain context. A generic RuntimeError('authentication failed') doesn't tell the caller whether they should retry, re-authenticate, or stop trying. A custom exception that carries structured data — like status codes, retry delays, and error identifiers — gives the calling code something to work with beyond a string message.

Defining a custom exception is as simple as subclassing Exception or one of its subclasses. By convention, custom exceptions end in 'Error' and inherit from Exception rather than BaseException. The standard library follows this pattern: LookupError subclasses KeyError, IndexError; OSError wraps system-level errors. Your domain classes should follow the same principle.

The real power comes from adding constructor arguments beyond the message. When you catch a custom exception, you can inspect those attributes to decide how to respond. For example, a RateLimitedError with a retry_after attribute allows the caller to sleep that many seconds before retrying — something a plain string message cannot express programmatically.

One common pattern is a base class for your project's exceptions (e.g., MyProjectError) that inherits from Exception, then specific subclasses for each domain failure. This lets callers catch the base class if they want a general safety net, or catch specific subclasses for targeted handling. Avoid inheriting from multiple exception classes — it creates confusion about which catch clause will match.

Remember that custom exceptions are also classes, so you can add methods to them. A RetryableError might have a method to compute an exponential backoff. This is overkill for most cases but can be elegant in complex retry logic. In practice, storing attributes is enough.

import time
import random

# Step 1: Define a base exception for your library or application
class PaymentError(Exception):
    """Base exception for all payment-related errors."""
    pass

# Step 2: Subclass for specific failure modes
class InsufficientFundsError(PaymentError):
    def __init__(self

Exception Chaining with 'raise X from Y': Preserving the Full Traceback

When you catch a low-level exception and raise a higher-level one — for example, catching a database connection error and raising a ServiceUnavailableError — you have a choice. You can raise the new exception directly: raise ServiceUnavailableError(). Or you can chain it: raise ServiceUnavailableError() from original_exception. The difference is whether the original traceback survives.

Without 'from', the new exception's __cause__ is left as None. When Python prints the traceback, you only see the new exception. The original error — which query failed, what the database error code was — is gone. During an incident, this forces engineers to reconstruct the root cause from context: which request was in flight, which query was running, what the log line right before the exception says. That reconstruction can take hours.

With 'raise X from Y', Python sets __cause__ on the new exception to the original. The traceback shows both, with the message 'The above exception was the direct cause of the following exception:' between them. The original line number, stack frames, and error message are all preserved.

You can also use implicit chaining without 'from'. If an exception is raised while another exception is being handled and you don't explicitly catch the original, Python sets __context__ instead of __cause__. The traceback then shows 'During handling of the above exception, another exception occurred:' and both are printed. This is automatic, but it's less clear than explicit chaining because the new exception isn't necessarily a direct transformation of the original. Explicit 'from' is preferred whenever you intentionally translate an exception.

The one case where you should use 'from None' is when you want to suppress the original exception entirely — for example, when a socket error should be presented as a simple ConnectionFailedError without exposing internal network details. 'raise ConnectionFailedError('timeout') from None' clears the chain and prints only the new exception. Use this sparingly, because it hides information that may be critical for debugging.

import sqlite3

class DatabaseError(Exception):
    """Domain-level error for database operations."""
    pass

def get_user_email(user_id: int) -> str:
    """
    Fetches user email from the database.
    Example of bad, good, and suppress chaining.
    """
    try:
        conn = sqlite3.connect('users.db')
        cursor = conn.cursor()
        cursor.execute("SELECT email FROM users WHERE id = ?", (user_id,))
        row = cursor.fetchone()
        if row is None:
            raise ValueError(f"User {user_id} not found")
        return row[0]
    except sqlite3.Error as e:
        # BAD: no chaining — original traceback lost
        raise DatabaseError("Database operation failed")

def get_user_email_chained(user_id: int) -> str:
    """
    Same logic but preserves the original exception via 'from'.
    """
    try:
        conn = sqlite3.connect('users.db')
        cursor = conn.cursor()
        cursor.execute("SELECT email FROM users WHERE id = ?", (user_id,))
        row = cursor.fetchone()
        if row is None:
            raise ValueError(f"User {user_id} not found")
        return row[0]
    except sqlite3.Error as e:
        # GOOD: chain the low-level error into the domain exception
        raise DatabaseError("Database operation failed") from e

def get_user_email_suppressed(user_id: int) -> str:
    """
    Intentional suppression — hide internal details.
    """
    try:
        conn = sqlite3.connect('users.db')
        cursor = conn.cursor()
        cursor.execute("SELECT email FROM users WHERE id = ?", (user_id,))
        row = cursor.fetchone()
        if row is None:
            raise ValueError(f"User {user_id} not found")
        return row[0]
    except sqlite3.Error:
        # Use 'from None' to suppress the original cause
        raise DatabaseError("Database operation failed") from None


if __name__ == '__main__':
    # Example 1: no chaining
    print("=== Without chaining ===")
    try:
        get_user_email(1)
    except DatabaseError as e:
        import traceback
        traceback.print_exc()
        # Output: only DatabaseError: Database operation failed
        # Original sqlite3.Error is lost.

    print("\n=== With chaining (from e) ===")
    try:
        get_user_email_chained(1)
    except DatabaseError as e:
        traceback.print_exc()
        # Output: both DatabaseError and its cause (sqlite3.Error)
        # The line 'The above exception was the direct cause...' appears.

    print("\n=== Suppressed chaining (from None) ===")
    try:
        get_user_email_suppressed(1)
    except DatabaseError as e:
        traceback.print_exc()
        # Output: only DatabaseError — original cause hidden

The else Block in Depth: Why It Exists and the Bug It Prevents

The else block is the most misunderstood part of Python's exception handling syntax. Most tutorials mention it briefly and move on. That's a mistake, because the problem it solves is subtle and the consequences of ignoring it are real.

Here's the core issue. When you put post-success logic inside the try block, you're expanding the blast radius of your except handlers. Any exception that code raises — a TypeError in your data processing, a KeyError in a dictionary lookup, a logic bug you haven't discovered yet — will be caught by your except handlers, which were written to handle a completely different failure mode. The error is silently misclassified.

The else block prevents this by drawing a hard structural boundary: only the one risky operation lives in try, and your except handlers apply only to that operation. Everything that should run after success lives in else, where exceptions surface normally without being caught by the wrong handler.

The before/after pattern below makes this concrete. It's a small change that has prevented several production incidents where a data processing bug was being swallowed by a database exception handler and the symptom looked like a connection issue.

import json
import logging

logger = logging.getLogger("io.thecodeforge")


# ----------------------------------------------------------------
# BEFORE: post-success logic inside try — dangerous
# ----------------------------------------------------------------
def parse_config_dangerous(raw: str) -> dict:
    """
    Bug: if json.loads() succeeds but the subsequent processing raises
    a KeyError or TypeError, that exception is caught by the
    json.JSONDecodeError handler — wrong handler, wrong response.
    """
    try:
        data = json.loads(raw)
        # This processing logic should NOT be inside try.
        # A bug here looks like a JSON parse error to the except below.
        result = {
            "host": data["database"]["host"],   # KeyError if structure wrong
            "port": int(data["database"]["port"]) # ValueError if port is a string
        }
        return result
    except json.JSONDecodeError as e:
        # This handler was written for JSON parse failures.
        # It will now also silently catch KeyError and ValueError from above.
        logger.error("Invalid JSON — returning defaults: %s", e)
        return {\"host\": \"localhost\", \"port\": 5432}\n\n\n# ----------------------------------------------------------------\n# AFTER: post-success logic in else — correct\n# ----------------------------------------------------------------\ndef parse_config_safe(raw: str) -> dict:\n    \"\"\"\n    Safe version: try holds only the risky parse operation.\n    The except handler applies only to JSONDecodeError.\n    Post-success processing lives in else — a KeyError here\n    surfaces as an unhandled exception, not a misclassified parse error.\n    \"\"\"\n    try:\n        data = json.loads(raw)\n    except json.JSONDecodeError as e:\n        # This handler now applies exclusively to JSON parsing failures.\n        logger.error(\"Invalid JSON — returning defaults: %s\", e)\n        return {\"host\": \"localhost\", \"port\": 5432}\n    else:\n        # This code only runs when json.loads() succeeded.\n        # Exceptions here are NOT caught by the JSONDecodeError handler above —\n        # they propagate normally, which is exactly the right behaviour.\n        return {\n            \"host\": data[\"database\"][\"host\"],\n            \"port\": int(data[\"database\"][\"port\"])\n        }\n\n\nif __name__ == '__main__':\n    valid_json = '{\"database\": {\"host\": \"db.prod\", \"port\": \"5432\"}}'\n    broken_structure = '{\"database\": {}}' # missing host and port keys\n    invalid_json = 'not json at all'\n\n    print(\"=== Valid JSON, valid structure ===\")\n    print(parse_config_safe(valid_json))\n\n    print(\"\\n=== Invalid JSON — both versions return defaults ===\")\n    print(parse_config_safe(invalid_json))\n\n    print(\"\\n=== Valid JSON, broken structure (dangerous version) ===\")\n    # Bug: KeyError is swallowed by JSONDecodeError handler — returns default silently\n    print(parse_config_dangerous(broken_structure))\n\n    print(\"\\n=== Valid JSON, broken structure (safe version) ===\")\n    # Correct: KeyError propagates — the caller sees the real bug\n    try:\n        print(parse_config_safe(broken_structure))\n    except KeyError as e:\n        print(f\"Caught real error: KeyError {e} — structure was wrong, not JSON\")",
        "output": "=== Valid JSON, valid structure ===\n{'host': 'db.prod', 'port': 5432}\n\n=== Invalid JSON — both versions return defaults ===\nInvalid JSON — returning defaults: ...\n{'host': 'localhost', 'port': 5432}\n\n=== Valid JSON, broken structure (dangerous version) ===\nInvalid JSON — returning defaults: 'host'\n{'host': 'localhost', 'port': 5432}\n\n=== Valid JSON, broken structure (safe version) ===\nCaught real error: KeyError 'host' — structure was wrong, not JSON"
      }

else Block Use-Case Table: When to Use else vs. Putting Logic in try

Deciding whether to put code in the else block or inside try depends on whether that code can raise an exception that should be handled differently from the risky operation itself. The table below summarises common scenarios.

| Scenario                                      | Put in try?   | Put in else?   | Why?                                                                 |
|-----------------------------------------------|---------------|----------------|----------------------------------------------------------------------|
| Risky operation: opening a file               | Yes           | —              | The only line that can raise FileNotFoundError etc.                   |
| Processing: parsing file contents             | No            | Yes            | A parsing KeyError is not an IO error; should propagate separately.  |
| Validation: checking data integrity           | No            | Yes            | A validation error is a logic bug, not an environment failure.       |
| Updating cache after a successful DB write    | No            | Yes            | A cache connection failure is a different concern from DB failure.   |
| Renaming a temporary file after success       | No            | Yes            | If rename fails, that's a different error than the original write.   |
| Logging success (e.g., statsd increment)      | No            | Yes            | Logging failure should be silent or handled elsewhere, not catch the original error. |
| Cleanup that must run regardless (close fd)   | No            | No (finally)   | finally is for unconditional cleanup.                                |
| Code that cannot raise any exception          | No            | No (after)     | If no risk, put it after the entire try-except-else-finally block.   |
| Calling an API that has its own retry logic   | Yes           | —              | The API call is the risky operation itself.                          |
| Sequential risky operations (file then parse) | Separate try   | —              | Use separate try blocks per operation or extract into a function.    |

Common Mistake: Swallowing Exceptions with Bare except

The single most dangerous pattern in exception handling is a bare except: that does nothing. It can turn a manageable bug into silent data corruption.

There are two variants and it's worth being precise about what each one actually catches.

A bare 'except:' (no class specified) catches absolutely everything — including BaseException subclasses like KeyboardInterrupt and SystemExit. This means Ctrl+C during a long operation won't interrupt it, and sys.exit() calls won't work as expected. You are catching things the language explicitly designed to always propagate.

'except Exception:' is slightly more disciplined — it catches all subclasses of Exception but correctly leaves KeyboardInterrupt and SystemExit alone, since those inherit from BaseException directly, not Exception. However, it still catches far too much: ValueError, TypeError, AttributeError, and every other general exception that almost certainly indicates a bug in your own code rather than something you should handle silently.

Imagine a payment processing pipeline where a network timeout occurs. A bare except: pass hides the timeout and carries on as if the charge succeeded, leading to a duplicate charge on the next retry. There is no log, no metric, no alert. The bug is invisible until a customer calls.

The fix is always to name the exception you expect. If you genuinely must catch a broad range, log it at critical level and re-raise immediately. The monitoring system cannot fix what it cannot see.

import logging
logger = logging.getLogger("io.thecodeforge.payment")


# ----------------------------------------------------------------
# WRONG — never do this
# ----------------------------------------------------------------
def process_payment_dangerous(amount: float):
    try:
        charge_api(amount)
    except:  # Catches KeyboardInterrupt, SystemExit, and every bug in charge_api
        pass  # Silent. No log. No metric. No alert. No retry. Just nothing.


# ----------------------------------------------------------------
# ALSO WRONG — slightly less bad, still a trap
# ----------------------------------------------------------------
def process_payment_still_wrong(amount: float):
    try:
        charge_api(amount)
    except Exception:
        pass  # At least KeyboardInterrupt works now. Still logs nothing.


# ----------------------------------------------------------------
# CORRECT — production-grade pattern
# ----------------------------------------------------------------
def process_payment(amount: float):
    """
    Catches only the exceptions we can meaningfully respond to.
    Everything else is logged and re-raised so it surfaces properly.
    """
    try:
        charge_api(amount)
    except TimeoutError:
        # Specific: we know what this is, we know how to respond
        logger.warning("Payment API timeout for amount=%.2f — will retry", amount)
        return None
    except Exception as e:
        # Unexpected: we don't know what this is, so we cannot handle it safely.
        # Log at critical so it pages, then re-raise so execution stops here.
        logger.critical(
            "Unexpected error in payment processing for amount=%.2f",
            amount,
            exc_info=True  # Includes full traceback in the log entry
        )
        raise  # Re-raise: let it surface rather than continue in a broken state
    else:
        logger.info("Payment of %.2f processed successfully", amount)
        return True


def charge_api(amount: float):
    """Placeholder — simulates the external API call."""
    if amount > 10000:
        raise RuntimeError("Amount exceeds single-transaction limit")
    print(f"Charged: {amount}")

Nesting try Blocks: When and Why It Makes Sense

Sometimes a single try-except isn't enough. You may need to handle different failure modes at different granularities — the availability of a resource is a different kind of failure from the validity of its contents, and conflating the two makes both harder to handle correctly.

Nesting try blocks is a legitimate tool, but it comes with a discipline requirement: the outer try handles resource acquisition and availability errors, the inner try handles data processing and validation errors. Never go deeper than two levels. If you find yourself at a third level, the function is doing too much — extract the inner logic into a separate function that has its own try-except.

A real example: reading a configuration file. The outer try handles whether the file exists and whether we can open it. The inner try handles whether its contents are valid JSON. A corrupt file is not the same as a missing file — different error messages, potentially different recovery strategies — and the two levels make that separation structurally obvious.

import json
from pathlib import Path
import logging

logger = logging.getLogger("io.thecodeforge.config")


def load_config(path: str