Errors & Exceptions

int("abc") raises a ValueError. That is int working correctly — it was asked for something impossible and said so.

try:
    quantity = int(answer)
except ValueError:
    quantity = 0

If the try block finishes, the except is skipped entirely. If it raises, the rest of the block is abandoned and the except runs instead.

Your task: convert each answer to a whole number, using 0 for the ones that will not parse. Print one line per answer, then the total:

12
0
7
0
19

This code has a spelling mistake in it — quantitiy — and it prints a report full of zeros without a word of complaint. The bare except: catches the NameError along with everything else.

That is the case against catching broadly: without the handler this would have stopped on line one and told you exactly what was wrong.

Your task: narrow the except to ValueError, then fix the NameError it exposes. The output should be:

36
0
21
57

Each line is the quantity times three, with 0 for anything unparseable.

as error hands you the exception object. str(error) is the message Python wrote, and type(error).__name__ is the class name.

Between them you can log a line that names the problem, which is the difference between a report somebody can act on and one that says "something went wrong".

Your task: for each answer, print either the number or a line naming the exception and its message:

12
ValueError: invalid literal for int() with base 10: 'twelve'
7

Several except blocks can follow one try, and the first matching one wins. That lets each kind of failure get the response it deserves rather than one shared fallback.

Your task: rate(hits, attempts) should hand back the percentage. A non-numeric input is a ValueError and should give -1; zero attempts is a ZeroDivisionError and should give 0.0, because nobody attempting anything is a real answer rather than bad data.

75.0
0.0
-1

else runs only when the try raised nothing. finally runs either way — exception or not, return or not.

else matters because code that belongs after a successful attempt should not sit inside the try, where an exception it raises would be caught by a handler written for something else.

finally is for cleanup that must happen: closing a file, releasing a lock. It runs even while an exception is on its way up to crash the program.

Your task: for each answer, print the number on success or the failure on error, then done either way:

ok 12
done
failed twelve
done

raise reports a problem your own code has found. Doing it where data arrives means everything below can trust what it is holding.

if quantity < 0:
    raise ValueError(f"quantity must not be negative: {quantity}")

Put the offending value in the message. "invalid quantity" sends someone hunting; "quantity must not be negative: -3" does not.

Your task: write parse_quantity(text). It returns a whole number, and raises ValueError with a message containing the offending value when the number is negative. Rubbish text already raises ValueError from int(), so that case needs nothing.

12
quantity must not be negative: -3

This function catches every failure and returns 0. The import runs, the report is produced, and three of the numbers in it are wrong with nothing anywhere to say so.

Handling an error means doing something about it. Returning a plausible value and saying nothing is not handling — it is hiding.

Your task: keep the program running, but make each failure visible. Print a line naming the bad value, count them, and leave that row out of the total rather than counting it as zero:

skipped: twelve
skipped: 
Total: 19
Skipped: 2

The blank value prints as an empty string after the colon and a space.

Two ways to deal with something that might not be there:

# check first
if "region" in config:
    region = config["region"]
else:
    region = "eu"

# or try it
try:
    region = config["region"]
except KeyError:
    region = "eu"

Python leans towards the second — it reads as one attempt rather than two lookups, and it cannot go stale between the check and the use. For a dictionary specifically, .get() says the same thing shorter, which is why it exists.

Your task: write setting(config, key, fallback) using try/except KeyError, then print three calls:

9000
eu
30

Sometimes you catch an exception only to say something the deeper code could not know — which row, which file, which user — and then let it continue on its way.

A bare raise inside an except re-raises the exception being handled, with its original traceback intact. Writing raise error would work and would lose part of that.

except ValueError as error:
    print(f"row {n}: {error}")
    raise

Your task: load(rows) should print which row failed and then let the exception through. The caller catches it, so the program finishes:

row 3 failed: invalid literal for int() with base 10: 'x'
stopped after 2 good rows