Session 11 - Exception Handling & Modules and Packages | DSMP 2022 - 23

Exception handling is framed as the practical bridge between two kinds of failures in Python: errors caught during code compilation (syntax errors) and problems that surface only when the program runs (exceptions). The session starts by separating where things go wrong—during compilation, Python flags syntax issues when the code doesn’t match language rules; during execution, Python raises exceptions when the program logic encounters runtime conditions it can’t handle. That distinction matters because it determines what kind of fix is needed: syntax errors are resolved by debugging the code itself, while exceptions require defensive logic so the program can recover gracefully.

The class then walks through common exception types that beginners repeatedly hit. Syntax errors include missing punctuation like parentheses, missing colons, misspelled keywords (e.g., writing “if” incorrectly), and indentation mistakes—treated as a special kind of syntax-related failure in Python. Runtime exceptions are grouped into recognizable categories: IndexError when accessing list elements that don’t exist; ModuleNotFoundError when importing a module name that doesn’t exist; KeyError when a dictionary key is missing; TypeError when an operation is applied to an incompatible type; ValueError when a function receives an input of the right type but an invalid value; NameError when referencing variables that were never defined; and AttributeError when trying to access attributes or methods that an object doesn’t have.

From there, exception handling is presented as a user-safety and security tool, not just a debugging convenience. When exceptions occur, Python prints a “stack trace” with file names and line numbers—useful for developers, but harmful for end users because it looks frightening and can break user trust. It also risks exposing technical details that attackers could leverage. The remedy is to wrap risky code in try-except blocks so the program can catch specific failures and show controlled, friendly messages instead of raw tracebacks.

The session emphasizes structured handling: multiple except blocks for different error types, plus a final generic except to catch anything unexpected. It stresses that the generic handler must come last; otherwise it “steals” control from more specific handlers. It also introduces the full control-flow model of try, except, else, and finally: else runs only when the try block succeeds; finally runs in both success and failure cases and is used for cleanup—closing files, database connections, or sockets—so resources don’t remain open.

Next comes the concept of raising exceptions on purpose. Python allows developers to “raise” errors at any point in the logic, enabling custom control over failure conditions beyond what Python automatically detects. A banking-style example illustrates this: a withdrawal method raises an exception when the requested amount is invalid (e.g., negative or exceeding balance). The session connects raise to catch: the raised exception object is caught by the matching except block, where it can be handled.

Finally, the class shows why custom exception classes can be valuable. While built-in exceptions often suffice, custom exceptions let an application encode domain-specific failure behavior. A practical “Google login” scenario demonstrates this: if login happens from an unauthorized device, a custom SecurityError exception is raised, caught, and used to trigger actions like logging out from all devices and closing connections. The takeaway is that custom exceptions improve modularity and clarity by keeping application-specific logic inside the right components rather than scattering it across the codebase.