Start with the error, not the whole screen
When a program fails, the output may contain several lines of file names and function calls. You do not need to understand them all at once. First, find the error type and its message. These tell you what kind of failure occurred and, often, what the program was trying to do. A message such as “division by zero” describes a failed operation; it does not necessarily explain why the divisor became zero.
Next, note when the error appeared and what you did immediately beforehand. Did it happen when the program started, after you entered a value, or only on a particular page? That context helps you reproduce the problem. Keep the full error output while investigating: the short message is useful, but the stack trace often tells you where to look.
Follow the stack trace to your code
A stack trace records the chain of function calls active when an error occurred. Each entry, often called a frame, may show a file name, line number, function name, and line of code. In Python, the calls are displayed from the earlier caller toward the operation that failed. Other tools may display frames in a different order, so check the labels rather than assuming the top line is always the cause.
For a small example, use Python 3.10 or later and a text editor. Save these lines as example.py, then run python example.py in a terminal. On a system where that command points to another Python version, use the command for your Python 3 installation instead: def average(total, count): return total / count def report(): print(average(10, 0)) report()
The resulting traceback may differ slightly by Python version, but it will identify example.py and end with ZeroDivisionError: division by zero. Read the frames as a path: the script called report(), report() called average(10, 0), and average() attempted total / count. The last operation is where execution failed. The earlier calls explain how the program reached it. The line number is a starting point for inspection, not proof that the entire bug began on that line.
Separate the failure from its cause
In the example, changing the division line might prevent the immediate error, but the right fix depends on what count means. If zero represents invalid input, check it before calling average() and give the caller a clear response. If a zero count is expected, decide what result the program should produce in that case. The traceback shows the failure; you still need to decide which behavior is correct.
In a larger application, frames may pass through a framework, a library, or runtime code. Look for a frame in a file you maintain, then examine the values passed into and out of that function. The nearest line in your code is often a good place to begin, even if the error itself appears inside a library. Avoid editing library code simply because its frame appears in the trace.
Also check whether the reported line is only a symptom. A missing value, for example, might originate several calls earlier and fail only when another function tries to use it. Trace the relevant value backward: where was it created, changed, or passed along?
Turn the trace into a debugging experiment
Make a small hypothesis before changing code: “count is zero when report() calls average().” Then verify it with a debugger or a temporary print statement near that call. Check the actual value and its type; a value that looks like a number might be a string, while a value expected to exist might be missing. Change one thing at a time so you can tell what affected the result.
After a fix, run the same steps that produced the error. Then try a nearby case, such as a nonzero count and a zero count, to check that the intended behavior holds. If the problem could recur, add an automated test covering the failing input. Remove temporary diagnostic output when it is no longer useful.
If you ask someone else for help, share the error type, message, relevant stack frames, the smallest code sample that reproduces the issue, and what you expected to happen. Remove passwords, tokens, personal data, and private file paths first. A stack trace is not a verdict about your ability: it is a map of what the program did before it stopped.
