Chapter 8 — Error Handling & Exceptions

The why

Errors are data — ignoring them is a design decision too. Every program encounters errors: files that don't exist, networks that timeout, users who type letters where numbers are expected. How you handle these errors separates toy code from production code.

Python's philosophy is EAFP: "Easier to Ask Forgiveness than Permission." Instead of checking every condition upfront, try the operation and handle the exception if it fails.

Core concepts: Exception handling

try/except Basics

# Specific exception
try:
    result = 10 / 0
except ZeroDivisionError:
    print("Cannot divide by zero")
 
# Multiple exceptions
try:
    value = int("abc")
except ValueError:
    print("Invalid number")
except TypeError:
    print("Wrong type")
 
# Catch multiple in one block
try:
    value = int("abc")
except (ValueError, TypeError) as e:
    print(f"Error: {e}")
 
# Get exception object
try:
    value = int("abc")
except ValueError as e:
    print(f"Error: {e}")  # Error: invalid literal for int()

Rule: Always catch specific exceptions. Never use bare except: — it catches everything, including KeyboardInterrupt.

else and finally

try:
    file = open("data.txt")
    data = file.read()
except FileNotFoundError:
    print("File not found")
else:
    # Runs only if try succeeded
    print(f"Read {len

Use case for finally: Close files, release locks, disconnect from databases.

Raising Exceptions

def divide(a, b):
    if b == 0:
        raise ValueError("Cannot divide by zero")
    return a / b
 
# Chaining exceptions
try:
    value = int("abc")
except ValueError

Best practices:

• Raise specific exceptions (ValueError, not Exception)
• Include helpful error messages
• Chain exceptions with from when wrapping

Custom Exceptions

# Base exception for your app
class AppError(Exception):
    pass
 
# Specific exceptions
class ValidationError(AppError):
    pass
 
class NotFoundError(AppError):
    pass
 
# Usage
def get_user(user_id):
    if

Hierarchy:

AppError
├── ValidationError
├── NotFoundError
└── PermissionError

EAFP vs LBYL

# LBYL: Look Before You Leap
if key in dictionary:
    value = dictionary[key]
else:
    value = default
 
# EAFP: Easier to Ask Forgiveness
try:
    value = dictionary[key]
except KeyError:
    value = default
 
#

Python prefers EAFP — it's more readable and often faster.

Common mistakes

Practice: Prove your Mastery

Interview Questions

Summary

• try/except catches exceptions. Always catch specific exceptions.
• else runs on success. finally always runs (cleanup).
• raise signals errors. raise from chains exceptions.
• Custom exceptions: inherit from Exception, one base per app.
• EAFP: try, then handle. LBYL: check first, then try.

Quick recall

I want to…
├── Catch error → try: ... except SpecificError:
├── Cleanup → finally:
├── Success only → else:
├── Signal error → raise ValueError("message")
├── Chain → raise NewError from old_error
└── Custom → class MyError(Exception): pass

Self-Check Quiz

Create a base exception class for your app (e.g., AppError). Create specific exceptions that inherit from it (ValidationError, NotFoundError). This allows callers to catch specific errors or all app errors with one handler.