Beginner: Chapter 5 - Python: Error Handling and Debugging Basics | The GPM

The GPM
Dec 25, 2025
7 min read

Python programs rarely work perfectly the first time, so understanding errors and debugging is essential for writing reliable code. Error handling lets your program fail gracefully instead of crashing, while debugging techniques help you find and fix problems faster.

Types of Errors in Python

Python programs typically run into two broad categories of problems: syntax errors and runtime exceptions. Syntax errors occur when the code violates Python’s grammar rules, such as missing colons or unmatched parentheses, and they prevent the program from running at all. Runtime exceptions happen while the program is executing, for example when dividing by zero, accessing a missing list index, or converting invalid input to an integer.

Logic errors are different because the code runs without raising an exception but produces the wrong result. These are often the hardest to catch because the interpreter does not complain, and you only notice them when outputs do not match expectations. Recognizing which type of error you are dealing with helps you choose the right debugging strategy.

Basic Exception Handling with try and except

Python uses exceptions to signal that something has gone wrong during execution. Without handling, an unhandled exception stops the program and prints a traceback. The try and except keywords allow you to intercept those exceptions and respond in a controlled way. The general pattern is to place risky code in a try block and handle specific problems in one or more except blocks.

For example, if user input might not be a valid integer, you can wrap the conversion in a try block and catch ValueError in except. This prevents the program from crashing and lets you display a friendly message or ask for input again. By naming the exception as a variable, you can also inspect or log the error message for diagnostics.

Using a bare except with no exception type is usually discouraged because it catches everything, including programmer mistakes like NameError or KeyboardInterrupt. It is better to catch specific exception classes so that unrelated issues still surface, making bugs easier to notice and fix during development.

Using else and finally Blocks

Alongside try and except, Python provides else and finally clauses to give finer control over error handling flow. The else block executes only if the code in try completes without raising any exception, making it a good place for logic that should run only when everything went well. This keeps your handling code separate from your normal success path.

The finally block runs regardless of whether an exception occurred or not. It is commonly used for cleanup tasks such as closing files, releasing network connections, or resetting resources. Even if you return early from inside try or except, the finally block still executes, which guarantees that cleanup happens consistently.

Combining these pieces, you can build robust structures where try contains the risky operation, except handles specific failures, else contains follow up actions in the success case, and finally cleans up resources no matter what. This pattern is especially valuable when working with external systems that must always be released properly.

Raising Exceptions Intentionally

Sometimes your code detects a situation that should be treated as an error even if Python itself would not raise one. In these cases, you can raise your own exceptions with the raise statement. For instance, a function that expects a positive number might check the argument and raise ValueError if it does not meet the requirement.

Raising exceptions makes your functions safer and more predictable because invalid states cannot silently propagate through the program. Callers then handle these conditions using their own try and except blocks or allow them to bubble up to higher levels. Defining custom exception classes that inherit from Exception or a more specific base lets you create domain specific error types with clearer semantics.

By documenting which exceptions a function may raise, you help future readers and maintainers understand how to use it correctly. Clear messages passed to exceptions also make debugging easier when an error eventually appears in logs or tracebacks.

Common Exception Types to Know

Python includes many built in exception classes that cover frequent problems. ValueError indicates that a function received an argument of the right type but inappropriate value, such as converting the string "abc" to an integer. TypeError means an operation or function was applied to an object of an unsuitable type, like adding a string to an integer.

IndexError is raised when code tries to access a list or tuple position that does not exist, and KeyError appears when a dictionary lookup uses a missing key. FileNotFoundError signals that an attempt to open a file failed because it does not exist at the specified path. ZeroDivisionError happens whenever you divide by zero in arithmetic expressions.

Knowing these common exceptions helps you both interpret tracebacks quickly and write targeted except blocks that only capture the situations you expect. In larger projects, this discipline prevents unrelated errors from being silently swallowed.

Reading and Using Tracebacks

When Python encounters an unhandled exception, it prints a traceback that shows where the error occurred and how the program reached that point. The traceback lists the call stack from the outermost frame to the innermost, including file names, line numbers, and the lines of code involved. The final line shows the exception type and message.

Learning to read tracebacks is a key debugging skill. Start from the bottom, where the exception is reported, and work upwards to see how your functions were called. Cross checking line numbers and code snippets helps you locate the exact operation that failed. Once you find the relevant part of the code, you can add temporary print statements or use a debugger to inspect variables and state.

When logging errors in production systems, it is often useful to capture the full traceback as text. The traceback module and logging facilities can assist with this, enabling detailed bug reports that include stack information without printing directly to the console.

Simple Debugging with Print Statements

One of the most accessible debugging techniques is inserting print statements into your code to display variable values and control flow. By printing key variables before and after important operations, you can verify whether they hold the expected data at each stage. This method is particularly helpful for tracking down logic errors where no exception is raised.

For example, if a loop is not behaving as expected, you might print the loop index and current element on each iteration to see how they change. In conditionals, printing which branch is executed can reveal cases where a condition does not evaluate the way you think it does. Gradually narrowing the region where behavior diverges from expectations helps you find the root cause.

Although print debugging is simple and effective, it can clutter code if overused. After fixing an issue, it is good practice to remove or comment out temporary print statements so the program output remains clean and focused on actual user facing information.

Using the Built In Debugger

Python also includes an interactive debugger that allows you to pause execution, inspect variables, and step through code line by line. The built in tool can be invoked from the command line or embedded directly inside a script. By setting breakpoints, you can stop the program at strategic points and examine its state before continuing.

Inside a debugging session, you can list source code around the current line, view local and global variables, evaluate expressions, and move forward one step at a time. This level of control is particularly valuable for complex logic, nested loops, or recursive functions where simple prints are insufficient. Being able to inspect the call stack helps you understand how you arrived at a given piece of code.

Many modern editors and IDEs expose the debugger through a graphical interface with buttons for stepping, inspecting variables, and adding breakpoints. Learning to use these tools effectively can significantly speed up your workflow and make tracking down subtle bugs much less frustrating.

Defensive Programming and Best Practices

Good error handling begins before errors occur by writing code that anticipates and guards against invalid conditions. Input validation is a major part of this approach: always check that function arguments fall within expected ranges or formats before using them. For example, confirm that indexes are within bounds and that user supplied paths do not break assumptions about directory structure.

Clear, consistent error messages make it easier to understand what went wrong when exceptions do arise. When you design public functions or modules, think about which exceptions should be allowed to propagate and which should be wrapped with more context before re raising. Avoid catching exceptions too broadly or ignoring them, because this can hide real problems and make debugging much harder later.

Automated testing complements defensive programming by catching regressions early. Unit tests exercise individual functions with both normal and edge case inputs, verifying that they either return correct results or raise appropriate exceptions. When a test fails, it immediately points you to the function and scenario that need attention, turning debugging into a focused investigation instead of a guessing game.

Building a Debugging Mindset

Effective debugging is as much about mindset as it is about tools. Start by reproducing the problem reliably, then form a hypothesis about the cause, design an experiment to test it, and observe the results. Each cycle should bring you closer to the source of the bug. Keeping notes about what you have tried prevents you from repeating ineffective approaches.

When a bug is especially stubborn, simplify the environment by reducing inputs or isolating the problematic function in a small script. Often, cutting away unrelated complexity reveals that the real issue is much smaller than it first appeared. Collaborating with others, explaining your code aloud, or using rubber duck debugging can also expose assumptions you did not realize you were making.

By combining structured error handling, careful reading of tracebacks, practical debugging techniques, and defensive design, you can make Python programs far more robust. Over time, the patterns of common mistakes become familiar, and fixing them turns from a source of frustration into an integral part of developing reliable software.

Disclosure: