The Errors Your Data Actually Throws

You already know how to read a traceback and how to catch what you expect. What is worth having by heart is which three exceptions data actually produces, because recognising the name tells you what went wrong before you read another word.

The first two are honest and immediate: they fail at the line that made the wrong assumption. The third is the one that costs an afternoon, because it usually fires a long way from wherever the value actually went missing.

.get() asks the same question as square brackets and declines to raise when the answer is no. With one argument it hands back None; with two, whatever you nominated.

scores = {"amara": 18, "ben": 6} print(scores.get("dara"))     # Noneprint(scores.get("dara", 0))  # 0print(scores["dara"])         # KeyError: 'dara'

Try itAdd "dara": 11 to the dictionary and run it again.

.get() reads without writing. .setdefault() reads, and writes the default into the dictionary if the key was missing — which is exactly what building a grouping needs.

students = [    {"name": "Amara", "track": "python"},    {"name": "Ben", "track": "ml"},    {"name": "Chidi", "track": "python"},] by_track = {} for student in students:    by_track.setdefault(student["track"], []).append(student["name"]) print(by_track)

Try itAdd a fourth student on a track nobody else is on, and run it again.

The first student on each track finds no list, so setdefault puts an empty one in and returns it. Every later student on that track finds the list already there and appends to it. No conditional, and no key checked twice.

There are two ways to write code that might fail, and Python has a stated preference between them. Check first, or attempt and handle the failure.

# Look before you leap: check, then act.if "dara" in scores:    total += scores["dara"] # Easier to ask forgiveness: act, then handle the failure.try:    total += scores["dara"]except KeyError:    pass

The second is the more Pythonic of the two, and not merely by convention. The first asks the dictionary the same question twice — once to check, once to fetch — and leaves a gap between the two in which the answer could change. In a program with threads, or where anything else can touch that dictionary, the gap is a real bug and not a theoretical one.

Checking first helps when failure is the common case rather than the exception. Setting up a try is nearly free; raising and catching is not, so a lookup that misses nine times in ten is better off with the in check.

A bare except: catches everything, including the typo three lines down and the interrupt you pressed to stop the program. It is the single fastest way to turn a five-second bug into an hour-long one.

# Hides every mistake in the block, including your own typos.try:    total += scores[name]except:    total += 0 # Names the one failure you actually anticipated.try:    total += scores[name]except KeyError:    total += 0

The second version still crashes if scores turns out to be None, and that is the point — that is a different bug, it deserves a traceback, and the narrow except is what lets it get one.

.get() is a good tool with one sharp edge: reaching for it reflexively converts a loud, precise failure into a quiet, vague one that surfaces somewhere else entirely.

minutes = record.get("minutes")   # missing key → None, no complaintaverage = minutes / chapters      # TypeError, forty lines later

The TypeError names the division, which is the one line in the program that is not the problem. Had the first line raised a KeyError, it would have quoted the missing key and pointed at the record that lacked it.