Exception hierarchy — Hinglish notes

1.3.7 · Coding › Python Intermediate

Structure: General se Specific Tak

Python mein har exception BaseException se inherit karti hai. Yeh raha derived-from-scratch logic:

Python ko BaseException top pe kyun chahiye?

Saare exceptions ka EK common ancestor hone ke liye
Taaki except Exception: "normal" errors ko catch kar sake bina system-exit events ko pakde

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: Catching Kaise Kaam Karta Hai

FIRST PRINCIPLES SE: Jab Python raise dekhta hai, woh exception hierarchy mein upar jaata hai aur matching except clause dhundta hai.

Step-by-step:

Exception raise hui: KeyError('missing_key')
Python check karta hai: Kya except KeyError hai? ✓ Match!
Nahi mila toh parent check karo: Kya except LookupError hai? ✓ Match!
Nahi mila toh grandparent check karo: Kya except Exception hai? ✓ Match!
BaseException tak ya koi handler nahi mila tab tak continue karo (crash)

Yeh ordering kyun matter karti hai:

# ❌ 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")

Kyun? Python handlers ko top se bottom check karta hai. KeyError IS-A Exception hai, isliye pehla handler hamesha jeet jaata hai.

# ✅ 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: Hierarchy Ka Faayda Uthana

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)

Yeh step kyun? Hum handlers ko specific → general order mein rakhte hain. ZeroDivisionError pehle check hota hai kyunki woh most specific hai. Agar hum ise catch na karein, toh ArithmeticError handler (iska parent) ise pakad leta—lekin hum division by zero ke liye custom messaging chahte hain.

1e308 / 1e-10 overflow kyun karta hai? Yeh floats hain, integers nahi. Float division jo maximum representable float (~ $1.8 \times 1 0^{308}$ ) se bada value produce kare, woh OverflowError raise karta hai. Note: integer division jaise 10**1000 / 10**999 overflow NAHI karta—woh simply 10.0 equal karta hai, kyunki Python result ko correctly promote karta hai. Overflow sirf tab hota hai jab float operands ka result float range se bahar jaaye.

Worked example Example 2: OSError Family ke Saath File Operations

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

Yeh step kyun? OSError 20+ file/network exceptions ka parent hai. FileNotFoundError aur PermissionError ko pehle catch karke, hum specific recovery logic dete hain (default config banana vs. bilkul fail hona). OSError handler unexpected file errors ke liye safety net hai (disk full, network drive disconnect, etc.).

Worked example Example 3: Common Ancestor ke Saath Multiple Exception Types

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

Yeh step kyun? Do alag handlers likhne ki (except IndexError aur except KeyError) bajaye, hum exploit karte hain ki dono LookupError se inherit karte hain. Yeh 80/20 principle hai—ek handler dono common lookup failures ko cover karta hai. Iska use karo jab tumhe har exception type ke liye alag recovery logic nahi chahiye.

Common Mistakes & Steel-manning

Common mistake Mistake 1: Normal Code Mein BaseException Pakadna

Galat Soch:

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

Kyun sahi lagta hai: "Main EVERY possible error pakadna chahta hoon!"

Kyun galat hai: BaseException mein SystemExit (sys.exit() se), KeyboardInterrupt (Ctrl+C), aur GeneratorExit shamil hain. Tumhara handler program termination signals ko swallow kar lega. User Ctrl+C dabaye? Tumhara code chalta rahega. Unit test sys.exit(1) call kare? Ignore ho jayega.

Fix:

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

Rule: "Catch-all" ke liye except Exception use karo. except BaseException ko sirf logging/cleanup frameworks ke liye reserve karo jo shutdown ke dauran bhi run karna chahte hain.

Common mistake Mistake 2: Specific Se Pehle General Handler

Galat Soch:

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

Kyun sahi lagta hai: "Main sabse important (general) handler pehle rakhunga."

Kyun galat hai: Python handlers ko sequentially check karta hai. Kyunki KeyError IS-A Exception hai, pehla handler hamesha match karta hai. Specific handler unreachable dead code ban jaata hai. Python 3.11+ toh tumhe iske baare mein warn bhi karta hai!

Fix:

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

Common mistake Mistake 3: Aise Exceptions Pakadna Jo Samajh Nahi Aate

Galat Soch:

try:
    value = int(user_input)
except Exception:  # ❌ int() kya errors raise kar sakta hai?
    return 0

Kyun sahi lagta hai: "Better safe than sorry—sab kuch pakad lo!"

Kyun galat hai: Overly broad handlers bugs ko mask kar dete hain. int() invalid input ke liye ValueError raise karta hai. Lekin agar tumhare code mein bug ho jo AttributeError cause kare? Tumhara handler silently 0 return kar deta hai, bug chhupa deta hai. Aur bura: agar memory corrupt ho aur MemoryError aaye? Tum 0 return karte ho crash karne ki jagah (jo MemoryError ke liye correct hai).

Fix:

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

Forecast-then-verify: Except clause likhne se pehle poochho, "Yeh code SPECIFICALLY kya exceptions raise kar sakta hai?" Docs dekho, IDE use karo, ya test karo. Sirf wahi catch karo.

Recall Feynman Explanation (12-saal ke bacche ko samjhao)

Socho tumhara teacher tumse saare animals organize karne ko bol raha hai. Tum keh sakte ho:

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

Python errors ke saath bhi yahi karta hai! "Animals" ki jagah humara "Exceptions" hai. "Mammals" ki jagah "ArithmeticError" (math problems) ya "LookupError" (kuch find nahi ho raha) hai.

Jab tum except Mammals likhte ho, tum automatically saare dogs aur cats pakad lete ho. Jab except Dogs likhte ho, tum SIRF dogs pakadते ho.

Rule: Agar tum dog pakadna chahte ho, tum "catch dogs" ya "catch mammals" ya "catch animals" keh sakte ho—teeno kaam karte hain kyunki dogs teeno families mein belong karta hai. Lekin agar tumhe sirf dogs se matlab hai, specific raho! "Catch dogs" kaho taaki accidentally cats na pakad lo.

Python mein: except KeyError (specific) vs except LookupError (KeyError + IndexError pakadta hai) vs except Exception (almost sab kuch pakadta hai).

Connections

1.3.06-TryExcept-Finally — Basic exception syntax (precise catching ke liye hierarchy use karo)
1.3.08-Custom-Exceptions — Hierarchy mein apne khud ke exception classes banao
1.3.09-Context-Managers — with statements use karo (jo internally exception handling pe rely karte hain)
2.1.04-Inheritance — Exception hierarchy class inheritance use karti hai (IS-A relationships)
3.2.05-Logging — Exceptions ko proper specificity ke saath log karo (bare except se swallow mat karo)

#flashcards/coding

Python ki exception hierarchy ki root kya hai?

BaseException (SystemExit, KeyboardInterrupt, aur Exception ka parent)

Normal error handling ke liye except BaseException ki jagah except Exception kyun use karna chahiye?

BaseException SystemExit aur KeyboardInterrupt ko catch karta hai, jo program termination aur Ctrl+C ko kaam karne se rok deta. Exception sirf normal errors pakadta hai.

KeyError aur IndexError dono ka parent exception kya hai?

LookupError (dono LookupError ke children hain)

Specific exception handlers general ones se pehle kyun aane chahiye?

Python handlers ko sequentially top-to-bottom check karta hai. Agar general handler (jaise except Exception) pehle aaye, toh woh child exceptions ko specific handlers se pehle pakad leta hai, unhe unreachable dead code bana deta hai.

ArithmeticError ke teen children batao

ZeroDivisionError, OverflowError, FloatingPointError

Agar tum KeyError raise karo aur tumhare handler mein sirf except LookupError ho toh kya hoga?

LookupError handler ise pakad lega, kyunki KeyError IS-A LookupError hai (inheritance)

Specific handlers ki jagah except OSError kab use karoge?

Specific handlers (FileNotFoundError, PermissionError) ke baad safety net ke roop mein, unexpected OS-level errors jaise disk full ya network failures ko pakadne ke liye

except Exception: pass production code mein kyun dangerous hai?

Yeh silently saari errors swallow kar leta hai, bugs sameta, debugging impossible ho jaati hai. Tumhe pata hi nahi chalta kab cheezein fail ho rahi hain.

Kya 10**1000 / 10**999 OverflowError raise karta hai?

Nahi—yeh 10.0 equal karta hai. Integer division correctly promote hota hai. OverflowError sirf FLOAT operands ke saath hota hai jinka result max float (~1.8e308) se zyada ho, jaise 1e308 / 1e-10.

Structure: General se Specific Tak

Derivation: Catching Kaise Kaam Karta Hai

Worked Examples

Common Mistakes & Steel-manning

Connections

Concept Map