Python Exception Handling Exercises: 20 Coding Problems with Solutions

try:
    user_input = input("Enter a number: ")
    number = int(user_input)
    print("You entered:", number)
except ValueError:
    print("Error: That was not a valid integer. Please enter a number.")Code language: Python (python)

Explanation:

• try:: Opens the guarded block. Python attempts to run every statement inside it. If any line raises an exception, execution jumps immediately to the matching except block.
• int(user_input): Converts the string to an integer. When the string contains non-numeric characters, Python raises a ValueError automatically, so you do not need to raise it manually here.
• except ValueError:: Catches only ValueError exceptions. Using a specific exception type instead of a bare except is best practice because it avoids silently swallowing unrelated errors.
• Print in the except block: Any code inside the except block runs only when the named exception is raised. Code after the entire try/except structure continues normally either way.

def safe_divide(a, b):
    try:
        result = a / b
        return result
    except ZeroDivisionError:
        print("Warning: Division by zero is not allowed.")
        return None

print(safe_divide(10, 2))   # 5.0
print(safe_divide(10, 0))   # NoneCode language: Python (python)

Explanation:

• result = a / b: Performs the division. When b is zero, Python raises ZeroDivisionError before assigning anything to result.
• except ZeroDivisionError:: Intercepts the error only when b is zero. All other exceptions (e.g., TypeError if non-numbers are passed) propagate normally, which is the correct behaviour.
• return None: Returns Python’s built-in null value as a safe sentinel. The caller can check if result is None: to detect the failure without catching an exception itself.
• Normal path: When b is non-zero, the except block is skipped entirely and return result executes as usual.

filename = "missing_file.txt"

try:
    with open(filename, "r") as f:
        content = f.read()
        print(content)
except FileNotFoundError:
    print(f"Error: The file '{filename}' was not found. Please check the filename and path.")Code language: Python (python)

Explanation:

• with open(filename, "r") as f:: The with statement is the recommended way to open files because it automatically closes the file handle even if an exception occurs. The "r" flag opens the file in read-only mode.
• FileNotFoundError: A subclass of OSError raised specifically when the path does not point to an existing file. Catching this precise type avoids masking other I/O errors such as permission denied.
• f-string in the message: Embedding {filename} in the error message gives the user actionable information without requiring them to search the traceback.
• Alternative: You can also use except FileNotFoundError as e: print(e.filename) to extract the filename directly from the exception object if you prefer not to store it in a variable beforehand.

items = ["apple", "banana", "cherry"]

try:
    index = int(input("Enter an index: "))
    print("Item:", items[index])
except ValueError:
    print("Error: Please enter a valid integer index.")
except IndexError:
    print(f"Error: Index {index} is out of range. "
          f"The list has {len(items)} items (valid indices: 0 to {len(items) - 1}).")Code language: Python (python)

Explanation:

• int(input(...)): Combines input reading and conversion in one step. If the user types a non-integer string, ValueError is raised before the list access is ever attempted.
• items[index]: Triggers IndexError when index is greater than or equal to len(items), or less than -len(items). Python supports negative indices (e.g., -1 for the last element), so values like -10 on a three-item list also cause this error.
• Multiple except clauses: You can stack as many except blocks as needed after a single try. Python checks them in order and runs only the first matching one.
• len(items) - 1: Computes the last valid index dynamically so the error message stays accurate even if the list changes size later.

capitals = {
    "France": "Paris",
    "Japan": "Tokyo",
    "Brazil": "Brasilia"
}

try:
    country = input("Enter a country name: ")
    capital = capitals[country]
    print(f"The capital of {country} is {capital}.")
except KeyError:
    print(f"Error: '{country}' was not found in the dictionary.")Code language: Python (python)

Explanation:

• capitals[country]: Direct bracket access raises KeyError immediately when the key does not exist. This is the idiomatic way to look up a dictionary value when you expect the key to be present and want to treat its absence as an error.
• except KeyError:: Catches the missing-key error and lets you respond with a custom message. The exception object contains the missing key value, so you can reference it in the message for clarity.
• Alternative – dict.get(): Using capitals.get(country) returns None silently when the key is missing, avoiding the need for a try/except block entirely. Choose get() when absence is a normal, expected condition, and use bracket access with exception handling when absence should be treated as an error worth reporting.
• Case sensitivity: Dictionary keys are case-sensitive in Python. Entering "france" instead of "France" would also trigger a KeyError. You could normalise input with country.title() or country.capitalize() to improve robustness.

def add_values(a, b):
    try:
        return a + b
    except TypeError:
        return "Error: incompatible types for addition."

print(add_values(10, 20))       # 30
print(add_values(10, "20"))     # Error: incompatible types for addition.Code language: Python (python)

Explanation:

• return a + b: The + operator works for numbers, strings, and lists, but mixing types that do not support addition together (such as int and str) causes Python to raise TypeError immediately.
• except TypeError:: Catches the type mismatch error specifically. Keeping the exception type narrow means other unexpected errors, such as a MemoryError, will still propagate and not be silently swallowed.
• return from the except block: Returning a value from inside an except clause is perfectly valid. The caller receives either the computed result or the error string and can check which one was returned.
• Note on "20" vs 20: add_values(10, "20") fails because Python will not silently coerce a string to an integer. If you want to support that, you would explicitly convert with int(b) or float(b) before adding, and handle the resulting ValueError separately.

def parse_and_divide(value, divisor):
    try:
        number = float(value)
        result = number / divisor
        return result
    except ValueError:
        return f"Error: '{value}' cannot be converted to a number."
    except ZeroDivisionError:
        return "Error: Cannot divide by zero."

print(parse_and_divide("abc", 2))   # Error: 'abc' cannot be converted to a number.
print(parse_and_divide("10", 0))    # Error: Cannot divide by zero.
print(parse_and_divide("10", 2))    # 5.0Code language: Python (python)

Explanation:

• float(value): Attempts to convert the string to a floating-point number. When the string is not numeric (e.g., "abc"), Python raises ValueError and the division line is never reached.
• number / divisor: Only executes if the conversion succeeded. If divisor is zero at this point, ZeroDivisionError is raised and the second except block takes over.
• Order of except clauses: Python tests each clause from top to bottom and runs only the first match. For unrelated exception types, the order does not matter practically, but it is good practice to list more specific exceptions before broader ones.
• Tuple shorthand: If you want identical handling for multiple types, you can write except (ValueError, ZeroDivisionError): in a single clause. Here they are kept separate because the error messages differ.

def read_file(filename):
    f = None
    try:
        f = open(filename, "r")
        content = f.read()
        return content
    except FileNotFoundError:
        return f"Error: '{filename}' not found."
    finally:
        if f:
            f.close()
        print("File closed.")

print(read_file("hello.txt"))
print("---")
print(read_file("missing.txt"))Code language: Python (python)

Explanation:

• f = None: Initialising f before the try block ensures the variable exists in the finally scope. If open() itself raises an exception (e.g., FileNotFoundError), f would never be assigned, so checking if f: before calling f.close() prevents a secondary AttributeError.
• finally:: This block runs unconditionally after the try and any matching except clause, whether the code succeeded, raised a caught exception, or raised an uncaught one. It is the correct place for cleanup logic.
• f.close(): Releases the operating system file handle. Leaving files open wastes resources and can cause data corruption or lock issues on Windows systems.
• Why not just use with?: The with open(...) as f: statement handles closing automatically and is the modern preferred approach. This exercise intentionally avoids it to demonstrate what with does under the hood and to prepare you for codebases that do not use it.

import math

def safe_sqrt(value):
    try:
        number = float(value)
    except ValueError:
        print(f"Error: '{value}' is not a valid number.")
    else:
        result = math.sqrt(number)
        print(f"Success: the square root of {number} is {result}")

safe_sqrt("25")    # Success: the square root of 25.0 is 5.0
safe_sqrt("abc")   # Error: 'abc' is not a valid number.Code language: Python (python)

Explanation:

• try contains only the risky line: Only float(value) sits inside try. This is intentional. If math.sqrt() were also inside try and it raised an error (e.g., on a negative number), that error would be caught by the except ValueError clause, which would be misleading.
• else:: Runs if and only if the try block completed without raising any exception. It is the correct place for code that depends on the success of the guarded operation but should not itself be protected by the same except clause.
• math.sqrt(number): Returns the square root as a float. It raises ValueError for negative inputs, but since it lives in the else block, that error is not caught here and would propagate to the caller – which is the correct and transparent behaviour.
• Clause order: The full order of clauses on a try statement is: try – except – else – finally. You can combine all four in a single structure when needed.

import json

def load_and_parse(filename, key):
    try:
        with open(filename, "r") as f:
            data = json.load(f)
        try:
            value = data[key]
            print(value)
        except KeyError:
            print(f"Error: key '{key}' not found in the data.")
    except FileNotFoundError:
        print(f"Error: file '{filename}' does not exist.")

load_and_parse("data.json", "name")     # Alice
load_and_parse("data.json", "email")    # Error: key 'email' not found in the data.
load_and_parse("missing.json", "name")  # Error: file 'missing.json' does not exist.Code language: Python (python)

Explanation:

• Outer try – file access: Wraps the file open and JSON parse operations. If either fails due to a missing file, the outer except FileNotFoundError catches it and the inner block never runs. This prevents a cascade of secondary errors when the prerequisite (the file) does not exist.
• Inner try – key lookup: Only reached when the file loaded successfully. It isolates the dictionary access so that a missing key is handled specifically without interfering with the outer error handler.
• json.load(f): Parses the entire file contents into a Python dictionary. It can raise json.JSONDecodeError if the file is not valid JSON. That exception is not caught here and would propagate up, which is intentional: the exercise focuses on nesting, not exhaustive handling.
• When to nest vs. stack: Use nested try blocks when later operations depend on the success of earlier ones and each needs its own handler. Use stacked (sequential) try blocks when operations are independent. Deeply nested structures (three or more levels) are usually a sign to refactor into separate functions.

def process_data(value):
    try:
        return int(value)
    except ValueError as e:
        print(f"[log] process_data failed: {e}")
        raise

# Calling code
try:
    process_data("abc")
except ValueError as e:
    print(f"[main] Caught re-raised exception: {e}")Code language: Python (python)

Explanation:

• except ValueError as e:: Binds the exception object to the name e, giving access to the error message via str(e) or directly inside an f-string.
• Bare raise: Re-raises the current active exception without modifying it. This is different from raise e, which would create a new traceback starting at that line. A bare raise preserves the full original traceback, which is critical for diagnosing where the error actually originated.
• Layered handling: After process_data logs and re-raises, execution resumes in the caller’s except block. The caller sees the same exception type and message, so it can respond independently – for example, by returning a default value, displaying a user-facing message, or logging again at a higher severity level.
• When to use this pattern: Re-raising is appropriate when a function has side effects to perform on failure (logging, metrics, cleanup) but is not the right place to make the final recovery decision. Avoid it when you actually want to suppress the error entirely – use a plain except without raise for that.

class InsufficientFundsError(Exception):
    def __init__(self, amount, balance):
        self.amount = amount
        self.balance = balance
        super().__init__(
            f"Cannot withdraw {amount}. Available balance: {balance}."
        )

class BankAccount:
    def __init__(self, balance):
        self.balance = balance

    def withdraw(self, amount):
        if amount > self.balance:
            raise InsufficientFundsError(amount, self.balance)
        self.balance -= amount
        print(f"Withdrew {amount}. New balance: {self.balance}.")

account = BankAccount(100)

try:
    account.withdraw(150)
except InsufficientFundsError as e:
    print(f"Error: {e}")Code language: Python (python)

Explanation:

• class InsufficientFundsError(Exception):: Inheriting from the built-in Exception class is the correct base for most custom exceptions. The custom __init__ stores the attempted amount and current balance as attributes, making them available for programmatic inspection in the caller, not just as a string message.
• super().__init__(...): Passes the human-readable message up to the base Exception class so that str(e) and print(e) work as expected without any extra effort from the caller.
• raise InsufficientFundsError(amount, self.balance): Raises the custom exception with contextual data baked in. The caller can catch it by name and access e.amount or e.balance for fine-grained error recovery, such as suggesting a valid withdrawal amount.
• Why not raise ValueError?: You could raise ValueError here, but then callers cannot distinguish an insufficient-funds error from any other value error in the system. A custom exception type creates a precise, unambiguous signal that belongs to your domain.

import json

class ConfigurationError(Exception):
    pass

def load_config(filename):
    try:
        with open(filename, "r") as f:
            return json.load(f)
    except FileNotFoundError as e:
        raise ConfigurationError(
            f"Could not load config file '{filename}'."
        ) from e

try:
    load_config("config.json")
except ConfigurationError as e:
    print(f"ConfigurationError: {e}")
    print(f"Caused by: {e.__cause__}")Code language: Python (python)

Explanation:

• raise NewException(...) from e: The from keyword explicitly chains the new exception to the original one. Python sets new_exception.__cause__ = e and marks the chain as explicit. When the traceback is printed in full, Python shows both exceptions with the message “The above exception was the direct cause of the following exception.”
• e.__cause__: The attribute holding the original exception. Accessing it programmatically lets you log or display the root cause without relying on the full traceback printout.
• Implicit chaining vs. explicit chaining: If you raise a new exception inside an except block without from, Python still attaches the original exception as __context__ (implicit chaining). Using from e is the explicit form and signals intent clearly. Using from None suppresses the chain entirely when you do not want the original cause exposed.
• Domain translation: FileNotFoundError is an OS-level detail. ConfigurationError is a business-level concept. Translating between them at the boundary of your module keeps the public API clean while still preserving the technical root cause for debugging.

while True:
    try:
        raw = input("Enter a positive integer: ")
        number = int(raw)
    except ValueError:
        print(f"Error: '{raw}' is not a valid integer. Try again.")
        continue
    if number <= 0:
        print(f"Error: {number} is not positive. Try again.")
        continue
    print(f"You entered: {number}")
    breakCode language: Python (python)

Explanation:

• while True:: Creates an infinite loop that runs until a break statement is reached. This is the standard Python idiom for “keep trying until success” input loops.
• except ValueError: ... continue: When the conversion fails, the error is printed and continue sends execution back to the top of the loop immediately, skipping the positivity check and the break.
• if number <= 0: ... continue: Handles the case where the input was a valid integer but fails the business rule. Using a plain if here (rather than raising an exception) is appropriate because this is an expected, normal condition rather than a programming error.
• break: Exits the loop only after both the type check and the value check have passed. Placing break at the end of the loop body after all validations makes the success condition easy to identify at a glance.
• Storing raw separately: Saving the raw input string in raw before converting allows the error message to echo back exactly what the user typed, which is more helpful than a generic “invalid input” message.

class SuppressError:
    def __init__(self, exception_type):
        self.exception_type = exception_type

    def __enter__(self):
        print("Entering context...")
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type is not None and issubclass(exc_type, self.exception_type):
            print(f"{exc_type.__name__} suppressed.")
            return True   # suppress the exception
        return False      # re-raise anything else

# Suppressed case
with SuppressError(ValueError):
    raise ValueError("bad value")
print("Outside context - execution continued.")

# Non-suppressed case
with SuppressError(ValueError):
    result = 1 + "two"    # raises TypeErrorCode language: Python (python)

Explanation:

• __enter__(self): Called at the start of the with block. Whatever it returns is bound to the variable after as. Here it returns self, but it could return any object – a file handle, a database cursor, or None.
• __exit__(self, exc_type, exc_val, exc_tb): Called when the with block exits, whether normally or due to an exception. When no exception occurred, all three parameters are None. When an exception did occur, they hold the type, value, and traceback respectively.
• issubclass(exc_type, self.exception_type): Using issubclass rather than exc_type == self.exception_type means the suppression also applies to subclasses of the target exception, which is consistent with how except clauses work.
• Return value of __exit__: Returning True is the signal to Python that the exception has been handled and should be suppressed. Returning False or None lets the exception propagate as if the with block were not there. This is the single most important rule of context manager exception handling.

class AppError(Exception):
    pass

class DatabaseError(AppError):
    pass

class AppConnectionError(DatabaseError):
    pass

# Catch at the most specific level
try:
    raise AppConnectionError("host unreachable")
except AppConnectionError as e:
    print(f"Caught as ConnectionError: {e}")

# Catch at the mid level
try:
    raise AppConnectionError("host unreachable")
except DatabaseError as e:
    print(f"Caught as DatabaseError: {e}")

# Catch at the base level
try:
    raise AppConnectionError("host unreachable")
except AppError as e:
    print(f"Caught as AppError: {e}")Code language: Python (python)

Explanation:

• Inheritance chain: AppConnectionError is a DatabaseError, which is an AppError, which is an Exception. Python’s except clause uses isinstance semantics, so catching any ancestor in the chain will intercept the raised exception.
• pass as body: For simple marker exceptions that carry no extra data beyond a message string, a body of pass is perfectly valid. The inherited __init__ from Exception already handles storing and displaying the message.
• Catching broadly vs. narrowly: Catching AppError in a top-level handler is a common pattern for “catch all application errors and log them.” Lower layers catch specific subclasses to attempt targeted recovery. This mirrors how logging frameworks and web frameworks handle request-level errors.
• Avoid shadowing built-ins: Python has a built-in ConnectionError (a subclass of OSError). Defining a class with the same name in module scope shadows it. Prefixing with your app or module name (as done here with AppConnectionError) prevents subtle bugs where code expecting the built-in gets yours instead.

import logging

logging.basicConfig(
    filename="app.log",
    level=logging.ERROR,
    format="%(asctime)s - %(levelname)s - %(message)s",
)

def divide(a, b):
    try:
        return a / b
    except ZeroDivisionError:
        logging.exception("Division failed: attempted to divide %s by zero.", a)
        return None

result = divide(10, 0)
print(f"divide(10, 0) returned {result}")

result = divide(10, 2)
print(f"divide(10, 2) returned {result}")Code language: Python (python)

Explanation:

• logging.basicConfig(...): Sets up the root logger with a file handler, minimum log level, and a format string. The %(asctime)s token adds a timestamp to every entry, making it much easier to trace when errors occurred in a running system.
• logging.exception(msg): Logs at ERROR level and automatically appends the current exception’s full traceback to the log entry. It must be called from inside an active except block so Python knows which exception to attach. Using this instead of logging.error(msg, exc_info=True) is simply more concise – they produce identical output.
• Log levels: Python’s logging hierarchy from lowest to highest is: DEBUG, INFO, WARNING, ERROR, CRITICAL. Setting level=logging.ERROR means only ERROR and CRITICAL messages are written. Adjust the level to DEBUG during development to capture more detail.
• Why log and return None?: The function handles the error internally (logging it) and returns a safe sentinel value. The caller does not need to know an exception occurred unless it checks the return value. This pattern suits library functions where the caller may not always want to write their own try/except.

import functools
def retry(times=3):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            last_exception = None
            for attempt in range(1, times + 1):
                try:
                    result = func(*args, **kwargs)
                    return result
                except Exception as e:
                    last_exception = e
                    print(f"Attempt {attempt} failed: {e}")
            raise last_exception
        return wrapper
    return decorator
# Simulated flaky function
call_count = 0
@retry(times=3)
def flaky_call():
    global call_count
    call_count += 1
    if call_count < 3:
        raise RuntimeError("temporary failure")
    print(f"Attempt {call_count} succeeded.")
    return "success"
print("Result:", flaky_call())Code language: Python (python)

Explanation:

• Three-level nesting: retry(times) is the factory that captures the argument. decorator(func) is the actual decorator that wraps the target function. wrapper(*args, **kwargs) is the replacement function that runs at call time. Each level closes over the variables of the level above it.
• @functools.wraps(func): Copies the original function’s __name__, __doc__, and other metadata onto wrapper. Without it, debugging tools and introspection would show wrapper instead of the real function name, making tracebacks harder to read.
• last_exception = e: Stores the most recent exception so it can be re-raised after all attempts are exhausted. Without this, the variable would go out of scope when the loop ends and the exception would be lost.
• Catching Exception broadly: The decorator catches all Exception subclasses by design, since it cannot know which specific errors the decorated function might raise. In production you would typically add an exceptions parameter so callers can restrict which error types trigger a retry – for example, @retry(times=3, on=requests.Timeout).

import threading

errors = []
lock = threading.Lock()

def divide(thread_name, a, b):
    try:
        result = a / b
        print(f"{thread_name}: {a} / {b} = {result}")
    except ZeroDivisionError as e:
        with lock:
            errors.append((thread_name, e))

divisors = [2, 0, 5, 0, 1]
threads = []

for i, divisor in enumerate(divisors, start=1):
    t = threading.Thread(
        target=divide,
        args=(f"Thread-{i}", 10, divisor)
    )
    threads.append(t)
    t.start()

for t in threads:
    t.join()

if errors:
    print("\nErrors collected:")
    for name, err in errors:
        print(f"{name}: {err}")Code language: Python (python)

Explanation:

• Exceptions do not cross thread boundaries: A ZeroDivisionError raised inside a threading.Thread target function terminates that thread silently. It never reaches the main thread’s exception handlers. The only way to surface it is to catch it inside the thread and communicate it through a shared data structure.
• with lock: before appending: The errors list is a shared mutable object. Multiple threads could attempt to append at the same moment, and while CPython’s GIL often makes individual list appends safe in practice, using a Lock is the correct and portable approach that works regardless of the Python implementation.
• t.join(): Blocks the main thread until the target thread finishes. Calling join() on every thread before reading errors guarantees that all threads have completed and all exceptions have been appended before the report is printed.
• Alternative – concurrent.futures: The ThreadPoolExecutor from concurrent.futures handles exception collection automatically. Calling future.result() re-raises the exception in the main thread. For new code that does not need direct thread control, this is the preferred approach.

def file_lines(filename):
    try:
        f = open(filename, "r")
    except IOError as e:
        print(f"Could not open file: {e}")
        return

    with f:
        for line in f:
            try:
                yield line.rstrip("\n")
            except RuntimeError as e:
                print(f"Generator cancelled: {e}")
                return

# Create a sample file for the demo
with open("sample.txt", "w") as f:
    f.write("Hello from line 1\nHello from line 2\nHello from line 3\n")

gen = file_lines("sample.txt")

# Get the first line normally
line = next(gen)
print(f"Line 1: {line}")

# Inject an exception before the second line
try:
    gen.throw(RuntimeError, "operation aborted")
except StopIteration:
    pass

print("Done.")Code language: Python (python)

Explanation:

• try/except IOError around open(): Guards the file open attempt at the very start of the generator. If it fails, the generator prints the error and exits via return, which raises StopIteration to the caller – the same signal as a generator that ran to completion.
• yield line.rstrip("\n") inside try: The key insight is that yield is a suspension point. When the generator is paused at yield, calling gen.throw(ExcType, msg) resumes it and immediately raises the given exception at that exact line. The surrounding try/except RuntimeError catches it there.
• return after catching the injected exception: Using return inside a generator raises StopIteration, signalling the caller that the generator is done. The caller wraps gen.throw() in a try/except StopIteration to handle this cleanly.
• generator.throw() vs. generator.close(): close() is a convenience method that calls throw(GeneratorExit). It is the mechanism Python uses to clean up generators when they are garbage-collected. throw() with a custom exception type lets you inject any signal you define – making it a flexible cancellation and communication channel in data pipelines.