在 Python 中，是否有可能在调用后发生异常，但"before"它后面的 try 块？

Question

给定一个函数调用和一个紧随其后的 try 块，是否存在调用正常返回但引发异常且未被 try 块捕获的情况？

例如：

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

有没有可能acquire_a_resource()正常返回，但resource.close()不会被召唤？

或者换句话说，是否存在以下情况：

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

会比示例#1更安全吗？

也许是因为与KeyboardInterrupt/线程/信号有关？

Answer 1

是的，至少在理论上是这样，尽管在CPython中不是(详见脚注)。 线程不是特别相关，但您的键盘中断场景恰到好处：

resource = acquire_a_resource()

调用该函数。 该函数获取资源并返回句柄，然后在分配给变量¹期间发生键盘中断。 所以：

try:

不运行 - 而是发生KeyboardInterrupt异常，保留当前函数并取消绑定变量。

第二个版本通过finally子句，因此假设if resource发现它是布尔值真值，resource.close()确实被调用。

(请注意，实际触发它通常非常困难：您必须恰到好处地安排中断的时间。 您可以通过例如，在try之前添加time.sleep(1)来大大增加比赛窗口。

在许多情况下，with语句效果很好：

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

其中close内置于__exit__方法中。 即使通过异常转义块，该方法也会运行。

---

¹一般来说，实现有义务完成获取的资源与变量的绑定，否则就会出现不可恢复的争用。 在CPython中，发生这种情况是因为解释器检查语句之间的中断，偶尔在源中的战略位置。

CPython实际上增加了另一个特例：

/* 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，靠近第 1000 行)。

所以实际上try线确实运行了，实际上，因为这里有一个SETUP_FINALLY。 我完全不清楚其他Python实现是否做同样的事情。