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
# 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 KeyError3. 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
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
ZeroDivisionError -> is Exception: True
IndexError -> is Exception: True
ZeroDivisionError is subclass of ArithmeticError: True
IndexError is subclass of LookupError: True6. 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.
Practice what you learned
1. Which class sits at the very root of Python's exception hierarchy?
2. What is the danger of using a bare `except:` clause?
3. ZeroDivisionError is a subclass of which class?
4. Accessing a missing key in a dictionary raises which exception?
5. Why does catching `Exception` also catch `ValueError`?
Was this page helpful?
You May Also Like
try-except in Python
How to use try-except blocks to catch and handle exceptions gracefully, including catching multiple exception types.
Custom Exceptions in Python
How to define your own exception classes to represent domain-specific errors, and how to raise and chain them properly.
finally Block in Python
How the finally clause guarantees cleanup code runs no matter what happens in a try block, including with return and break.
else Clause in Exception Handling
How the try/except/else clause runs code only when no exception occurred, and how it differs from finally.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics