How Does try-except Work in Python?

A try block holds the code that might fail, and the except clause names the type of error you want to handle. When the error happens, the except clause runs instead of the rest of the try block.

def parse_int(text):
    try:
        return int(text)
    except ValueError:
        return None


print(parse_int('42'))        # 42
print(parse_int('hello'))     # None

# Without a handler the error travels up to the caller.
try:
    int('hello')
except ValueError as err:
    print('ValueError:', err)

When int raises a ValueError inside the try block, the except clause runs and the function gives back None. When nothing goes wrong, the except clause is skipped completely and the value from the try block is returned.

The as err part attaches the error object to a name, and that is what lets you read its message. Without it you can still catch the error, but you cannot look at it, and all you get is the traceback.

The important point to remember is that an error which nobody catches does not stop quietly. It travels up the call stack, and if nothing higher up handles it either, Python prints the traceback and the program ends. So catching an error is a decision to deal with it in this function instead of passing it to the caller.

One more detail matters. Keep the try block as small as you can, and put only the statement that can really fail inside it. Everything else in that block is skipped when the error happens, including work that had nothing to do with the failure.

The four clauses always run in the same order. The try block runs first. If it raises an error, the matching except clause runs, and the else and finally clauses are skipped, except that finally always runs at the end. If the try block finishes without raising anything, the else clause runs first, and then finally runs.

The else clause exists for code that should run only when the try block succeeded. Putting that code in the else clause instead of at the end of the try block means that a failure inside the try block cannot accidentally skip it.

The finally clause always runs, no matter what happened before it. That makes it the right place for cleanup that must happen either way, such as releasing a lock, closing a connection, or rolling back a transaction. If the finally block itself raises an error, that new error replaces the one that was already on its way.

Catching an error and letting it travel upwards are two different design decisions about where the problem should be handled. Catching means that this function knows how to deal with the failure and can return something sensible. Letting it travel means that this function does not know enough to handle it, and that the caller, or the top level of the program, is in a better position to decide what to do.

Two rules of thumb are useful in an interview. Catch the narrowest exception type that you can really handle, and never use a bare except, because a bare except also swallows KeyboardInterrupt and SystemExit, which means the user cannot stop your program. And when you re-raise an error, use the plain raise rather than raise err, because the plain form keeps the original traceback attached, and that is what makes the error possible to diagnose later.

The difference shows up in what each clause is willing to swallow.

# Specific: only this failure is handled.
try:
    int('hello')
except ValueError as err:
    print('ValueError:', err)

# Broad: any ordinary exception is handled.
try:
    int('hello')
except Exception as err:
    print('Exception caught:', type(err).__name__)

# Bare: even KeyboardInterrupt is swallowed.
try:
    int('hello')
except:
    print('bare except')

All three of them print something, but they are not the same. The first one only handles a ValueError, so a TypeError from the same line would still travel upwards. The second one handles any exception that comes from Exception, which covers almost every error you would expect in normal operation. The third one catches everything, including KeyboardInterrupt and SystemExit, so a user who presses Ctrl-C inside that block would have their interrupt thrown away without a word.

That last point is why a bare except is nearly always a bug. KeyboardInterrupt is the normal way a person stops a running program, and SystemExit is how a clean shutdown is requested. Swallowing both of them means that the program cannot be stopped.

The right approach is to catch the specific error that you know how to handle. If you really need to catch everything at the edge of your program, use except Exception, write the error down with its traceback, and then decide on purpose whether to raise it again. Swallowing an error without recording it leaves no trace at all, and the failure shows up later as data that is mysteriously wrong.