Python Try Catch: Use except, else and finally Precisely

Start with a small, explicit task

Parse a fictional label count. Return a separate result for invalid integer text, build the label only after a successful conversion, and trace the final action. Then pass None to show that a different TypeError is not silently turned into the same invalid-text result.

Run the complete example

This original example was checked with Python 3.12.14. Save it as python_try_except.py and run it with Python 3.12. It uses only the standard library. The assertions check the stated results.

def parse_label(text, trace):
    try:
        count = int(text)
    except ValueError:
        trace.append("invalid text")
        return None
    else:
        trace.append("converted")
        return f"{count} labels"
    finally:
        trace.append("finished")
good_trace, bad_trace, type_trace = [], [], []
assert parse_label("8", good_trace) == "8 labels"
assert parse_label("eight", bad_trace) is None
try:
    parse_label(None, type_trace)
except TypeError:
    propagated = True
else:
    raise AssertionError("expected TypeError")
assert good_trace == ["converted", "finished"]
assert bad_trace == ["invalid text", "finished"]
assert propagated and type_trace == ["finished"]
print(good_trace)
print(bad_trace)
print(type_trace)

Explain the result

Valid text takes the else branch and returns a label. Invalid integer text takes except and returns None. Both returns still pass through finally, as the finished markers show. The label construction is outside the try body, keeping the conversion failure boundary narrow.

None causes TypeError rather than ValueError, so it propagates to the outer check after the finally action runs. This makes the helper’s input contract visible instead of making every programming mistake look like a rejected text value. The example traces a final action but does not acquire a resource; a context manager is often clearer for actual file cleanup.

Avoid these mistakes

Do not return from finally merely to force a success value: that can replace a pending return or suppress an exception. Avoid except Exception: pass as a default repair. Handle an error at the point where you can supply a meaningful response, and preserve other failures for the caller.