Reading crashes, working with files, and finding bugs

Read it from the bottom up. The last line names the kind of problem and describes it — for example NameError: name 'totl' is not defined, which means you misspelt a variable. That bottom line is usually all you need.

Above it is the traceback: the chain of function calls that led to the failure, oldest at the top, most recent at the bottom. When your own code called a library that failed, this chain shows which of your lines started it.

A few you will meet constantly. NameError: you used a name that does not exist, usually a typo. TypeError: you did something to the wrong kind of value, like adding a number to text. IndexError: you asked for position 10 of a list holding 3 items. KeyError: you asked a dictionary for a label it does not have. ValueError: the kind was right but the value was not, like int("hello").

The skill to build here is simply not flinching. The error message is the most helpful thing in the room; beginners skip past it and start guessing, which turns a thirty-second fix into an hour.

The shape is try: followed by the risky steps, then except SomeError: followed by what to do about it. If nothing goes wrong, the except block is skipped entirely.

Catch the specific error you expect, not everything. A bare except: swallows every problem including the ones you have not thought of, which turns a loud crash into silent wrong behaviour. That is strictly worse — a crash tells you something is broken, silence does not.

The harder judgement is when not to catch at all. If your program genuinely cannot continue sensibly, letting it stop is the right answer. Catching an error and carrying on with nonsense data causes bugs that surface much later and much further away, which are the expensive kind.

Everything held in a variable disappears when the program ends. A file is how you keep it. You open a file, read from it or write to it, and close it.

The safe pattern is with open("notes.txt") as f: — the with part guarantees the file is properly closed even if something goes wrong in the middle. Get into the habit of always using it.

CSV files are just text where each line is a row and commas separate the columns — the format spreadsheets export. Python's built-in csv module handles the fiddly cases for you, such as a value that itself contains a comma. Do not try to split on commas by hand; that works right up until it suddenly does not.

Start with printing. Put print statements at the points where you have an assumption — print the value going into a function and the value coming out. Most bugs turn out to be a value that was not what you assumed, and this finds them.

Then graduate to the debugger, which is much better. You click beside a line number to set a breakpoint, run the program, and it pauses there. You can then look at every variable, and step forward one line at a time watching what changes. In VS Code this is the Run and Debug panel.

The reason it beats printing is that you do not have to guess in advance what to look at. You pause and inspect everything, including the things you did not suspect.

The underlying method matters more than the tool: form one specific guess about what is wrong, work out what you would see if that guess were true, then check. Changing things at random until the symptom disappears usually hides the bug rather than removing it.

Any .py file is a module. If you have helpers.py containing a function called clean(), then in another file you write import helpers and call helpers.clean(), or from helpers import clean to use the name directly.

Python also ships with a large standard library — code that comes with the language, already tested, that you can import without installing anything. csv, math, random, json and collections are ones you will use constantly.

The habit worth forming: before writing something fiddly, check whether the standard library already has it. It usually does, and the version that ships with Python has been used by millions of people and has had its edge cases found already.