在python中，是否可能在调用之后但紧随其后的try块之前发生异常？

Question

Given a function call and a try block that immediately follows it, is there any scenario where the call returns normally but an exception is raised and not caught by the try block?

For example:

# example 1
resource = acquire_a_resource()
try:
    resource.do_something()
    # some more code...
finally:
    resource.close()

Is it possible that acquire_a_resource() returns normally but resource.close() will not be called?

Or in other words, is there any scenario where:

# example 2
resource = None
try:
    resource = acquire_a_resource()
    resource.do_something()
    # some more code...
finally:
    if resource:
        resource.close()

would be safer than example #1?

Maybe because of something to do with KeyboardInterrupt /threads/signals?

Answer 1

Yes, at least in theory, though not in CPython (see footnote for details). Threading is not particularly relevant, but your KeyboardInterrupt scenario is just right:

resource = acquire_a_resource()

calls the function. The function acquires the resource and returns the handle, and then during the assignment to the variable, ¹ the keyboard interrupt occurs. So:

try:

does not run—the KeyboardInterrupt exception happens instead, leaving the current function and unbinding the variable.

The second version passes through the finally clause, so assuming if resource finds it boolean-truth-y, resource.close() does get called.

(Note that actually triggering this is often very difficult: you have to time the interrupt just right. You can increase the race window a lot by, eg, adding a time.sleep(1) before the try .)

For many cases, a with statement works well:

with acquire_a_resource() as resource:
    resource.do_something()

where the close is built into the __exit__ method. The method runs even if the block is escaped via exception.

---

¹ In general, the implementation is obligated to complete the binding of the acquired resource to the variable, otherwise there's an irrecoverable race. In CPython this happens because the interpreter checks for interrupts between statements, and occasionally in strategic places in the source.

CPython actually adds another special case:

    /* Do periodic things.  Doing this every time through
       the loop would add too much overhead, so we do it
       only every Nth instruction.  We also do it if
       ``pendingcalls_to_do'' is set, i.e. when an asynchronous
       event needs attention (e.g. a signal handler or
       async I/O handler); see Py_AddPendingCall() and
       Py_MakePendingCalls() above. */

    if (_Py_atomic_load_relaxed(&_PyRuntime.ceval.eval_breaker)) {
        opcode = _Py_OPCODE(*next_instr);
        if (opcode == SETUP_FINALLY ||
            opcode == SETUP_WITH ||
            opcode == BEFORE_ASYNC_WITH ||
            opcode == YIELD_FROM) {
            /* Few cases where we skip running signal handlers and other
               pending calls:
               - If we're about to enter the 'with:'. It will prevent
                 emitting a resource warning in the common idiom
                 'with open(path) as file:'.
               - If we're about to enter the 'async with:'.
               - If we're about to enter the 'try:' of a try/finally (not
                 *very* useful, but might help in some cases and it's
                 traditional)
               - If we're resuming a chain of nested 'yield from' or
                 'await' calls, then each frame is parked with YIELD_FROM
                 as its next opcode. If the user hit control-C we want to
                 wait until we've reached the innermost frame before
                 running the signal handler and raising KeyboardInterrupt
                 (see bpo-30039).
            */
            goto fast_next_opcode;
        }

( Python/ceval.c , near line 1000).

So actually the try line does run, in effect, because there's a SETUP_FINALLY here. It's not at all clear to me whether other Python implementations do the same thing.