try, except, else, finally

Catching an error

int() can't convert five, so this program stops with a traceback:

age = int(input("Age: "))
print("Next year you'll be", age + 1)

Put the line that might fail inside try, and say what to do in except:

text = input("Age: ")
try:
    age = int(text)
    print("Next year you'll be", age + 1)
except ValueError:
    print("That's not a whole number.")
print("Done")

Python runs the trytryThe block that might raise an error. If a line in it raises one that an except names, Python jumps to that except. block. If a line in it raises a ValueError, Python jumps to the exceptexceptThe block that runs when the try block raises the error type it names, like except ValueError:. block for that type. That's how you handlehandleDeal with an error in an except block instead of letting it stop the program. Also called catching it. an error, also called catching it. Change the Input to 17 and run it again: the except block is skipped.

Where does the program go after the except? Predict:

try:
    print("start")
    number = int("five")
    print("converted")
except ValueError:
    print("handled")
print("after")

start
handled
after

If you picked the first answer, you pictured Python going back to finish the try block. It never does: the rest of the try block is skipped, and once the except block is done, the program continues after the whole statement. The line that failed never finished, so its assignment never happened. Predict:

try:
    age = int("five")
except ValueError:
    print("Not a number")
print(age)

Not a number
Traceback (most recent call last):
  File "<your code>", line 5, in <module>
    print(age)
          ^^^
NameError: name 'age' is not defined

If age had a value before the try (say age = 0 above it), the last line would print 0: the name keeps its old value, because the failed assignment never happened.

Always name the error

except: with no type catches every error, including your own typos:

else and finally

A try statement can have two more blocks. Predict the order:

try:
    print("start")
    int("five")
except ValueError:
    print("handled")
else:
    print("no error")
finally:
    print("finally")
print("after")

start
handled
finally
after

The elseelseA block after the excepts that runs only when the try block raised no error. block runs only when the try block had no error, like a loop's else, which runs only when there was no break (lesson 3.3). The finallyfinallyA block that runs last, whether or not there was an error. Used for cleaning up. block always runs: with no error, with an error that's handled, and even with one no except catches, where it runs just before the program stops with the traceback. It's for cleaning up, like closing a file (lesson 8.1).

Why not put "no error" code at the end of the try block? An error there would be caught by an except meant for something else. else keeps try to the line that might fail.

Validation done right

Lessons 3.5 and 5.8 checked text with isdigit() before converting. That's wrong in both directions. It turns away text int() accepts:

print(int(" 5 "), int("-5"))
print(" 5 ".isdigit(), "-5".isdigit())

And it lets through ፩, which int() can't convert (lesson 6.3), so 5.8's ask_number still stops with a ValueError if someone types it. The honest test is to try int() itself. Here's ask_number from lesson 5.8, rewritten with try. With isdigit(), it could never accept a temperature of -3:

def ask_number(prompt, low, high):
    while True:
        text = input(prompt)
        try:
            number = int(text)
        except ValueError:
            number = None
        if number is not None and low <= number <= high:
            return number
        print(f"Please enter a number from {low} to {high}.")

print(ask_number("Temperature: ", -10, 45))

There are names for the two styles. EAFPEAFPEasier to ask forgiveness than permission: just try it, and handle the error if it comes., "easier to ask forgiveness than permission", tries and handles the error. LBYLLBYLLook before you leap: check first (with isdigit, in, or if), then act., "look before you leap", checks first. For conversions, EAFP is usually right: int() knows exactly what it accepts. LBYL is fine for simple checks, like if key in prices.

An error raised inside a function can be caught by the code that called it. to_age doesn't catch it, so it goes up to the global code, which does: