finally & else — The Full Error Flow

By the end of this lesson you can:

• Put a happy-path block in else — code that runs only if try succeeded.
• Put cleanup code in finally — runs whether or not anything went wrong.
• Predict the exact print order of a try / except / else / finally block.
• Explain why finally still runs even if you return from try.

Suppose we open a file, do something with it, and want to print "File handled." at the end. Where should that print go?

try:
    f = open("notes.txt")
    text = f.read()
    f.close()
    print("File handled.")    # here?
except FileNotFoundError:
    print("Not found.")
    print("File handled.")    # or also here?

If we put it inside try, it's skipped on error. If we duplicate it into except, we're repeating ourselves. The right answer is finally:

try:
    f = open("notes.txt")
    text = f.read()
    f.close()
except FileNotFoundError:
    print("Not found.")
finally:
    print("File handled.")    # always runs — once

The full shape

try:
    # risky code
except SomeError:
    # runs if SomeError was raised
else:
    # runs only if no exception was raised in try
finally:
    # ALWAYS runs — exceptions, returns, breaks, anything

except blocks may be many, but else and finally can each appear at most once.

The order, exactly

Memorise this run-order. It's on every exam Python ever wrote:

Success path:        try → else → finally
Caught exception:    try → except → finally
Uncaught exception:  try → finally → propagate up
Return from try:     try → finally → return
break/continue:      try → finally → break/continue

The key insight: finally always runs, and it always runs before the program leaves the try block — even if a return, break, or exception is on its way out.

Why else?

You could put the happy-path code at the end of the try block — but then any exception it raises would also be caught, which is usually not what you want.

# Without else — the "report" call is also wrapped in the try
try:
    n = int(input("Number: "))
    use_it(n)                 # if this raises, the except catches!
except ValueError:
    print("Bad input.")

# With else — only int() is in the try
try:
    n = int(input("Number: "))
except ValueError:
    print("Bad input.")
else:
    use_it(n)                 # exceptions here are NOT caught above

The else block lets you keep the try small and focused on the risky line only.

Why finally?

For cleanup that must always happen — close a file, release a lock, log the action, restore a setting. The with statement handles file closing automatically for you, but the principle generalises:

def transfer(amount):
    print(f"Starting transfer of {amount}")
    try:
        bank.withdraw(amount)
        bank.deposit(amount)
    except BankError:
        print("Transfer failed — rolling back")
        bank.rollback()
    finally:
        bank.unlock()       # always release the lock!
    print("Transfer complete.")

If withdraw blew up, the lock would never release without finally. Now it always does — exception or not.

The surprise · finally beats return

Yes, even a return from inside try waits for finally to run first.

def f():
    try:
        return 1
    finally:
        print("cleanup!")     # this prints BEFORE the 1 is returned

result = f()
# cleanup!
print(result)
# 1

Some students find this magical. It's the whole point: cleanup is non-negotiable.

Be careful · finally can override return

If you return from finally itself, it replaces whatever the try was going to return. Almost always a bug:

def f():
    try:
        return 1
    finally:
        return 2       # ❌ silently replaces the 1!

print(f())             # 2

Rule: don't put return, break or continue inside finally. Use it for side-effects (close, log, unlock) only.

The story

Build withdraw.py. Every withdrawal must be logged — successful or not. Code:

# withdraw.py — every withdrawal logged, exception or no

from datetime import datetime

def log(line):
    with open("audit.log", "a", encoding="utf-8") as f:
        f.write(f"{datetime.now().isoformat(timespec='seconds')}  {line}\n")

def withdraw(balance, amount):
    log(f"ATTEMPT  {amount} from {balance}")
    try:
        amt = int(amount)
        if amt <= 0:
            raise ValueError(f"Non-positive amount: {amt}")
        if amt > balance:
            raise ValueError(f"Insufficient funds: have {balance}")
    except ValueError as e:
        log(f"FAIL     {e}")
        return None
    else:
        log(f"OK       new balance {balance - amt}")
        return balance - amt
    finally:
        log(f"DONE     transaction closed")

print(withdraw(100, 30))       # 70
print(withdraw(100, "fifty"))  # None  (bad input)
print(withdraw(50, 500))       # None  (insufficient)

Resulting audit.log

2026-05-27T19:14:02  ATTEMPT  30 from 100
2026-05-27T19:14:02  OK       new balance 70
2026-05-27T19:14:02  DONE     transaction closed
2026-05-27T19:14:02  ATTEMPT  fifty from 100
2026-05-27T19:14:02  FAIL     invalid literal for int() with base 10: 'fifty'
2026-05-27T19:14:02  DONE     transaction closed
2026-05-27T19:14:02  ATTEMPT  500 from 50
2026-05-27T19:14:02  FAIL     Insufficient funds: have 50
2026-05-27T19:14:02  DONE     transaction closed

Read the diff

Three things to notice. (1) Every call appends three lines to the log — ATTEMPT, then OK or FAIL, then DONE. The DONE always runs because it's in finally. (2) The else block computes the success log only on the happy path. (3) Even though the function returns from inside both branches, finally still runs first — exactly the "finally beats return" rule from the concept section.

The full block is try / except / else / finally. else runs only when the try finished without raising — perfect for "happy path" code that you don't want the except to catch. finally always runs — exceptions, returns, breaks, everything — so it's the place for cleanup like closing files or releasing locks. Never put return inside finally — it silently replaces what was being returned. with open(...) already gives you finally-style cleanup for free.