Exception hierarchy

The Structure: From General to Specific

Every exception in Python inherits from BaseException. Here's the derived-from-scratch logic:

WHY does Python need BaseException at the top?

To have ONE common ancestor for all exceptions
So except Exception: can catch "normal" errors without catching system-exit events

The Main Branches:

BaseException
├── SystemExit          # sys.exit() calls
├── KeyboardInterrupt   # Ctrl+C
├── GeneratorExit       # Generator cleanup
└── Exception           # ← Normal errors start here
    ├── StopIteration
    ├── ArithmeticError
    │   ├── ZeroDivisionError
    │   ├── OverflowError
    │   └── FloatingPointError
    ├── LookupError
    │   ├── IndexError
    │   └── KeyError
    ├── OSError
    │   ├── FileNotFoundError
    │   ├── PermissionError
    │   └── ConnectionError
    └── ... many more

Derivation: How Catching Works

FROM FIRST PRINCIPLES: When Python sees a raise, it walks up the exception hierarchy looking for a matching except clause.

Step-by-step:

Exception raised: KeyError('missing_key')
Python checks: Is there an except KeyError? ✓ Match!
If not found, check parent: Is there an except LookupError? ✓ Match!
If not found, check grandparent: Is there an except Exception? ✓ Match!
Continue until BaseException or no handler found (crash)

WHY this ordering matters:

# ❌ WRONG - Dead code below!
try:
    data[key]
except Exception as e:      # Catches EVERYTHING first
    print("General error")
except KeyError as e:        # NEVER REACHED - KeyError is a child of Exception
    print("Key missing")

WHY? Python checks handlers top to bottom. KeyError IS-A Exception, so the first handler always wins.

# ✅ CORRECT - Specific to general
try:
    data[key]
except KeyError as e:        # Checked first - catches KeyError
    print(f"Missing key: {e}")
except LookupError as e:     # Catches IndexError (sibling of KeyError)
    print(f"Lookup failed: {e}")
except Exception as e:       # Catches everything else
    print(f"Unexpected: {e}")

Worked Examples

Worked example Example 1: Exploiting the Hierarchy

def safe_divide(a, b):
    """Division with hierarchical error handling."""
    try:
        result = a / b
        return result
    except ZeroDivisionError:
        # Specific: only division by zero
        print("Cannot divide by zero")
        return None
    except ArithmeticError:
        # Parent of ZeroDivisionError, OverflowError, etc.
        print("Math operation failed")
        return None
    except Exception as e:
        # Catches any other error
        print(f"Unexpected error: {e}")
        return None
# Test cases
safe_divide(10, 2)      # Returns 5.0
safe_divide(10, 0)      # "Cannot divide by zero" (ZeroDivisionError)
safe_divide(1e308, 1e-10)  # OverflowError → ArithmeticError handler
#   (1e308 / 1e-10 = 1e318 exceeds max float ~1.8e308 → OverflowError)

Why this step? We order handlers specific → general. ZeroDivisionError is checked first because it's the most specific. If we didn't catch it, the ArithmeticError handler (its parent) would catch it instead—but we want custom messaging for division by zero.

Why does 1e308 / 1e-10 overflow? These are floats, not integers. Float division that produces a value larger than the maximum representable float (~ $1.8 \times 10^{308}$ ) raises OverflowError. Note: integer division like 10**1000 / 10**999 does NOT overflow—it simply equals 10.0, because Python promotes the result correctly. The overflow only happens with float operands whose result exceeds the float range.

Worked example Example 2: File Operations with OSError Family

def read_config(filepath):
    """Read config file with precise error handling."""
    try:
        with open(filepath, 'r') as f:
            return f.read()
    except FileNotFoundError:
        # Specific: file doesn't exist
        print(f"Config file {filepath} not found")
        return create_default_config()
    except PermissionError:
        # Specific: file exists but no read permission
        print(f"Permission denied for {filepath}")
        return None
    except OSError as e:
        # Parent of FileNotFoundError, PermissionError, etc.
        print(f"OS error accessing {filepath}: {e}")
        return None
 
# Why this ordering?
# - FileNotFoundError is a child of OSError
# - PermissionError is also a child of OSError
# - If we put `except OSError` first, the specific handlers never run

Why this step? OSError is the parent of 20+ file/network exceptions. By catching FileNotFoundError and PermissionError first, we provide specific recovery logic (create default config vs. fail entirely). The OSError handler is a safety net for unexpected file errors (disk full, network drive disconnect, etc.).

Worked example Example 3: Multiple Exception Types with Common Ancestor

def process_user_data(data, index, key):
    """Process data structure with multiple lookup types."""
    try:
        # Might raise IndexError (list/tuple) or KeyError (dict)
        item = data[index]
        value = item[key]
        return value
    except LookupError as e:
        # LookupError is parent of BOTH IndexError and KeyError
        print(f"Data lookup failed: {e}")
        return None
    except Exception as e:
        print(f"Unexpected error: {e}")
        return None
 
# Test cases
process_user_data([{'name': 'Alice'}], 0, 'name')  # Works
process_user_data([{'name': 'Alice'}], 5, 'name')  # IndexError → LookupError handler
process_user_data([{'name': 'Alice'}], 0, 'age')   # KeyError → LookupError handler

Why this step? Instead of writing two handlers (except IndexError and except KeyError), we exploit that both inherit from LookupError. This is the 80/20 principle—one handler covers both common lookup failures. Use this when you don't need different recovery logic for each exception type.

Common Mistakes & Steel-manning

Common mistake Mistake 1: Catching BaseException in Normal Code

Wrong Idea:

try:
    risky_operation()
except BaseException:  # ❌ TOO BROAD
    print("Something went wrong")

Why it feels right: "I want to catch EVERY possible error!"

Why it's wrong: BaseException includes SystemExit (from sys.exit()), KeyboardInterrupt (Ctrl+C), and GeneratorExit. Your handler will swallow program termination signals. User presses Ctrl+C? Your code keeps running. Unit test calls sys.exit(1)? Ignored.

The fix:

try:
    risky_operation()
except Exception:  # ✅ Catches normal errors, allows system exits
    print("Something went wrong")

Rule: Use except Exception for "catch-all". Reserve except BaseException for logging/cleanup frameworks that must run even during shutdown.

Common mistake Mistake 2: General Handler Before Specific

Wrong Idea:

try:
    data[key]
except Exception:       # ❌ Catches KeyError first
    handle_general()
except KeyError:        # Dead code - never reached
    handle_missing_key()

Why it feels right: "I'll put the most important (general) handler first."

Why it's wrong: Python checks handlers sequentially. Since KeyError IS-A Exception, the first handler always matches. The specific handler is unreachable dead code. Python 3.11+ even warns you about this!

The fix:

try:
    data[key]
except KeyError:        # ✅ Specific first
    handle_missing_key()
except Exception:       # General last (safety net)
    handle_general()

Common mistake Mistake 3: Catching Exceptions You Don't Understand

Wrong Idea:

try:
    value = int(user_input)
except Exception:  # ❌ What errors can int() raise?
    return 0

Why it feels right: "Better safe than sorry—catch everything!"

Why it's wrong: Overly broad handlers mask bugs. int() raises ValueError for invalid input. But what if you have a bug that causes AttributeError? Your handler silently returns 0, hiding the bug. Worse: what if memory is corrupted and MemoryError occurs? You return 0 instead of crashing (which is correct for MemoryError).

The fix:

try:
    value = int(user_input)
except ValueError:  # ✅ Catch ONLY the expected error
    return 0
# Other exceptions (like MemoryError) propagate correctly

Forecast-then-verify: Before writing an except clause, ask "What SPECIFIC exceptions can this code raise?" Use the docs, use an IDE, or test it. Catch only those.

Recall Feynman Explanation (Explain to a 12-year-old)

Imagine your teacher asks you to organize all animals. You might say:

LivingThings (top of tree)
- Animals
  - Mammals
    - Dogs, Cats, Whales
  - Birds
    - Parrots, Eagles

Python does the same with errors! Instead of "Animals," we have "Exceptions." Instead of "Mammals," we have "ArithmeticError" (math problems) or "LookupError" (can't find something).

When you write except Mammals, you catch all dogs and cats automatically. When you write except Dogs, you ONLY catch dogs.

The rule: If you want to catch a dog, you can say "catch dogs" OR "catch mammals" OR "catch animals"—they all work because dogs belong to all three families. But if you only care about dogs, be specific! Say "catch dogs" so you don't accidentally catch cats.

In Python: except KeyError (specific) vs except LookupError (catches KeyError + IndexError) vs except Exception (catches almost everything).

Connections

1.3.06-TryExcept-Finally — Basic exception syntax (use hierarchy for precise catching)
1.3.08-Custom-Exceptions — Create your own exception classes in the hierarchy
1.3.09-Context-Managers — Use with statements (which rely on exception handling internally)
2.1.04-Inheritance — Exception hierarchy uses class inheritance (IS-A relationships)
3.2.05-Logging — Log exceptions with proper specificity (don't swallow with bare except)

#flashcards/coding

What is the root of Python's exception hierarchy?

BaseException (parent of SystemExit, KeyboardInterrupt, and Exception)

Why should you use except Exception instead of except BaseException for normal error handling?

BaseException catches SystemExit and KeyboardInterrupt, which would prevent program termination and Ctrl+C from working. Exception catches only normal errors.

What is the parent exception of both KeyError and IndexError?

LookupError (both are children of LookupError)

Why must specific exception handlers come before general ones?

Python checks handlers sequentially top-to-bottom. If a general handler (like except Exception) comes first, it catches child exceptions before specific handlers can run, making them unreachable dead code.

Name three children of ArithmeticError

ZeroDivisionError, OverflowError, FloatingPointError

What happens if you raise KeyError and only have except LookupError in your handler?

The LookupError handler catches it, because KeyError IS-A LookupError (inheritance)

When would you use except OSError instead of specific handlers?

As a safety net after specific handlers (FileNotFoundError, PermissionError) to catch unexpected OS-level errors like disk full or network failures

What's the danger of except Exception: pass in production code?

It silently swallows all errors including bugs, making debugging impossible. You don't know when things fail.

Does 10**1000 / 10**999 raise OverflowError?

No—it equals 10.0. Integer division promotes correctly. OverflowError only occurs with FLOAT operands whose result exceeds the max float (~1.8e308), e.g. 1e308 / 1e-10.

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho yaar, Python ne saare exceptions ko ek family tree ki tarah organize kiya hai, jaise ek khandaan hota hai jahan sabka ek common daada hota hai. Yahan sabse upar BaseException baitha hai, uske neeche Exception aata hai, aur uske neeche chote-chote specific errors jaise KeyError, IndexError, ZeroDivisionError waghera. Core intuition ye hai ki jab tum kisi parent exception ko catch karte ho, toh uske saare children automatically catch ho jaate hain. Jaise agar tum "mammals" pakadne jaao, toh dogs bhi aa jaayenge kyunki dog ek mammal hai. Isi tarah except LookupError likhne se KeyError aur IndexError dono pakde jaate hain, kyunki ye dono LookupError ke bacche hain.

Ab ye baat kyun important hai? Kyunki Python except clauses ko top se bottom check karta hai, aur jo pehla match ho jaaye wahi jeet jaata hai. Isliye tumhe hamesha specific error pehle aur general error baad mein likhna hota hai. Agar tumne galti se except Exception sabse upar likh diya, toh neeche ka except KeyError kabhi chalega hi nahi—wo dead code ban jaayega, kyunki KeyError bhi toh ek Exception hi hai, aur pehla handler use pehle hi pakad lega. Ye ek bahut common mistake hai jo beginners karte hain.

Toh practical baat ye hai ki jab bhi error handle karo, sabse specific ancestor use karo jo tumhare kaam ke exceptions cover karta ho—na zyada broad, na zyada narrow. except BaseException toh bilkul avoid karo kyunki wo Ctrl+C (KeyboardInterrupt) aur system-exit tak pakad leta hai, jo tumhare program ko kabhi band hi nahi hone dega—bahut dangerous hai. Is hierarchy ko samajhne se tum "surgical precision" ke saath errors handle kar paoge, matlab exactly wahi pakadoge jo tumhe chahiye, aur baaki errors ko naturally aage jaane doge. Ye skill real projects mein bahut kaam aati hai jab tumhe clean aur robust code likhna ho.

The Structure: From General to Specific

Derivation: How Catching Works

Worked Examples

Common Mistakes & Steel-manning

Connections

Concept Map

Hinglish (regional understanding)

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Python Intermediate

Connections