Exceptions

Exceptions describe execution-time problems

Python can reject code before it runs when its syntax is invalid, but syntactically valid code can also fail while executing. Python calls these execution-time errors exceptions. For example, int("four") is valid code, yet the conversion cannot produce an integer and raises ValueError. Similarly, 1 / 0 raises ZeroDivisionError. If no code handles an exception, Python reports a traceback that identifies the route through source code to the point where it occurred. An exception is therefore not merely a printed message; it is an object-based control-flow event that can be handled, allowed to propagate to a caller, or left unhandled.

The exception type carries important meaning. ValueError says an operation received a value of an appropriate general type but an inappropriate value; TypeError commonly signals an operation applied to an unsuitable type. Choosing a handler based on that meaning is safer than treating every failure alike. This lesson is about handling expected, local conditions. Finding an unexpected defect through tracing and inspection belongs to debugging, and safe acquisition and closing of files belongs to the file lessons.

A try statement separates protected work from outcomes

A try statement begins by executing its try suite. If that suite completes normally, its except suites are skipped. If an exception occurs in the try suite, the rest of that suite is skipped and Python looks for a matching except clause. A matching handler runs, after which execution continues after the whole statement. If no handler matches, the exception propagates to an enclosing caller or becomes unhandled. A handler does not automatically catch a problem raised inside a different except suite.

Keep a try suite narrow. If a program intends to handle a conversion failure, the conversion—not unrelated printing, calculation, or state changes—belongs in the protected suite. A narrow suite makes the intended recovery clear and avoids mislabeling an unrelated bug as bad input. An else suite is useful for code that should run only when the try suite did not raise an exception. Keeping success-only work there avoids accidentally catching an exception from that work. A finally suite executes as the last task before the try statement completes, whether the protected work succeeded, was handled, or an exception is continuing outward. Do not use a return, break, or continue in finally to hide an exception; that makes control flow needlessly surprising.

Target the exception type and respect the hierarchy

Built-in exceptions are classes. BaseException is their common base; Exception is the usual base for ordinary application-level errors. An except SomeClass handler matches an instance of SomeClass or a subclass of it. It does not match one of its base classes. This is why order matters when two handlers overlap: Python executes the first matching handler. A handler for a subclass such as FileNotFoundError must appear before a handler for its superclass OSError if the program needs different responses.

For introductory code, prefer a handler for the specific problem you expect, such as except ValueError: around int(text). A bare except: is especially risky because it catches every exception derived from BaseException, including KeyboardInterrupt and SystemExit, which programs normally should not swallow. except Exception: is less broad but still inappropriate when the program only knows how to recover from one expected condition. If a handler cannot make a correct decision, allow the exception to propagate or, after adding needed context, re-raise it.

raise lets code state a violated contract explicitly. A function that requires a nonnegative value can raise ValueError when it receives a negative one. That is different from using exceptions as ordinary branching: test predictable conditions directly when a simple conditional expresses the rule. Raise an exception when the function cannot sensibly continue under its documented input contract.

Trace success and failure paths independently

To trace a try statement, first identify the operation inside try that can raise. Then follow two paths: the no-exception path runs else if present, then finally; the matching-exception path runs the matching handler, then finally. An unmatched-exception path still runs finally before carrying the exception outward. This procedure explains output without guessing and makes it easier to decide whether a handler’s response is appropriate.

Exception handling should preserve useful information. A helpful handler can report what input was invalid or return a clearly documented fallback. A harmful handler silently substitutes a value that makes later results misleading. The goal is neither to prevent all exceptions nor to make a program continue at any cost. The goal is to handle the specific failures the program understands, while leaving unexpected failures available for diagnosis.