Exceptions in Python

Analogy categoryAnalogies

1. Introduction

An exception is an event that disrupts the normal flow of a program's instructions, raised when Python encounters an error it cannot resolve on its own, such as dividing by zero, accessing a missing dictionary key, or opening a file that does not exist. Instead of crashing silently or continuing with corrupted state, Python raises an exception object that carries information about what went wrong.

🏏

Cricket analogy: When a batsman is given out via a faulty DRS review, the umpire doesn't let play continue as normal — a specific signal (the exception) is raised explaining exactly what went wrong, like ball-tracking failure.

Exceptions are distinct from syntax errors, which are caught before the program even runs. Once code is syntactically valid, exceptions are how Python signals runtime problems. Every exception in Python is an instance of a class, and all exception classes ultimately derive from a common ancestor, which is what makes it possible to catch groups of related errors with a single handler.

🏏

Cricket analogy: A no-ball for overstepping is spotted before the delivery even counts, like a syntax error caught pre-match, whereas a batsman getting run out mid-over is a runtime problem, since all such dismissals share the common ancestor of 'wicket'.

2. Syntax

python

# Raising an exception explicitly
raise ValueError("invalid input")

# An exception raised implicitly by an operation
result = 10 / 0        # raises ZeroDivisionError
my_list = [1, 2, 3]
my_list[10]             # raises IndexError
my_dict = {"a": 1}
my_dict["b"]             # raises KeyError

3. Explanation

Python organizes exceptions in a class hierarchy rooted at BaseException. Directly under it sits Exception, the base class for almost all errors that user code should catch or raise. BaseException also has siblings of Exception, namely SystemExit, KeyboardInterrupt, and GeneratorExit, which represent program-control signals rather than ordinary errors.

🏏

Cricket analogy: In the ICC's overall disciplinary structure, most player misconduct falls under standard code violations, but rare events like a match being abandoned for crowd safety sit alongside as sibling categories, not ordinary rule breaches.

Under Exception live the familiar built-in exception types: ArithmeticError (with ZeroDivisionError as a subclass), LookupError (with IndexError and KeyError as subclasses), TypeError, ValueError, AttributeError, FileNotFoundError (a subclass of OSError), and many more. Because these all inherit from Exception, a handler written for Exception will catch any of them, while a handler written for a specific subclass like ValueError only catches ValueError and its own subclasses.

🏏

Cricket analogy: Under general 'dismissal' errors sit specific types like 'run-out' (a subclass of fielding dismissals) and 'lbw'; an umpire trained to spot any dismissal catches all of them, but one trained only for 'stumping' catches just that.

Never catch exceptions with a bare except: clause. A bare except catches everything, including BaseException subclasses like KeyboardInterrupt (Ctrl+C) and SystemExit (raised by sys.exit()). This can make a program that should stop cleanly on Ctrl+C swallow the interrupt and keep running, which is almost never what you want. Catch Exception (or a specific subclass) instead of using a bare except:.

Understanding the hierarchy matters when designing error handling: catch the most specific exception type that is meaningful for your logic, and only fall back to the broader Exception class when you genuinely need to handle 'anything that could go wrong' the same way, such as logging and re-raising.

🏏

Cricket analogy: A captain should set a specific field for a known threat like a left-arm swing bowler, and only fall back to a generic 'defensive ring' field when facing an unpredictable batting lineup where anything could happen.

4. Example

python

def describe_exception(exc):
    print(f"{type(exc).__name__} -> is Exception: {isinstance(exc, Exception)}")

try:
    1 / 0
except ZeroDivisionError as e:
    describe_exception(e)

try:
    [1, 2, 3][10]
except IndexError as e:
    describe_exception(e)

print("ZeroDivisionError is subclass of ArithmeticError:",
      issubclass(ZeroDivisionError, ArithmeticError))
print("IndexError is subclass of LookupError:",
      issubclass(IndexError, LookupError))

5. Output

text

ZeroDivisionError -> is Exception: True
IndexError -> is Exception: True
ZeroDivisionError is subclass of ArithmeticError: True
IndexError is subclass of LookupError: True

6. Key Takeaways

Exceptions are objects raised when a runtime error occurs and disrupt normal program flow.
All exceptions derive from BaseException; most user-facing errors derive from Exception.
Built-in exceptions form a hierarchy, e.g. ZeroDivisionError is a subclass of ArithmeticError.
Avoid bare except: since it also catches KeyboardInterrupt and SystemExit.
Catching a base class like Exception also catches all of its subclasses.
Understanding the hierarchy helps you choose the most specific exception type to catch.