python - 为什么我不能在 python 中处理 KeyboardInterrupt？

Question

我正在 Windows 上编写 python 2.6.6 代码，如下所示:

try:
    dostuff()
except KeyboardInterrupt:
    print "Interrupted!"
except:
    print "Some other exception?"
finally:
    print "cleaning up...."
    print "done."

dostuff() 是一个永远循环的函数，从输入流中一次读取一行并对其进行操作。当我按下 ctrl-c 时，我希望能够停止它并进行清理。

实际上发生的是 except KeyboardInterrupt: 下的代码根本没有运行。唯一会打印的是“清理...”，然后会打印如下所示的回溯:

Traceback (most recent call last):
  File "filename.py", line 119, in <module>
    print 'cleaning up...'
KeyboardInterrupt

因此，异常处理代码没有运行，并且回溯声称在 finally 子句期间发生了键盘中断，这没有意义，因为按 ctrl-c 是导致该部分运行的原因首先!甚至通用的 except: 子句也没有运行。

编辑:根据评论，我将 try: block 的内容替换为 sys.stdin.read()。问题仍然完全按照描述发生，finally: block 的第一行运行，然后打印相同的回溯。

编辑#2:如果我在读取后添加了几乎任何内容，则处理程序将起作用。所以，这失败了:

try:
    sys.stdin.read()
except KeyboardInterrupt:
    ...

但这有效:

try:
    sys.stdin.read()
    print "Done reading."
except KeyboardInterrupt:
    ...

这是打印的内容:

Done reading. Interrupted!
cleaning up...
done.

所以，出于某种原因，“阅读完毕”。行被打印，即使异常发生在前一行。这不是一个真正的问题——显然我必须能够在“try” block 内的任何地方处理异常。但是，打印无法正常工作 - 之后它不会像预期的那样打印换行符! “Interrupted”打印在同一行......之前有一个空格，出于某种原因......？无论如何，在那之后代码会做它应该做的事情。

在我看来，这是在阻塞系统调用期间处理中断的错误。

Answer 1

不幸的是，异步异常处理不可靠(信号处理程序引发的异常、通过 C API 的外部上下文等)。如果代码中有一些关于哪些代码负责捕获它们的协调，则可以增加正确处理异步异常的机会(调用堆栈中的最高可能值似乎合适，除了非常关键的函数)。

被调用的函数 (dostuff) 或堆栈下方的函数本身可能会捕获您没有/无法解释的 KeyboardInterrupt 或 BaseException。

这个简单的案例在 python 2.6.6 (x64) interactive + Windows 7 (64bit) 中运行良好:

>>> import time
>>> def foo():
...     try:
...             time.sleep(100)
...     except KeyboardInterrupt:
...             print "INTERRUPTED!"
...
>>> foo()
INTERRUPTED!  #after pressing ctrl+c

编辑:

经过进一步调查，我尝试了我认为其他人用来重现该问题的示例。我很懒所以我把“finally”省略了

>>> def foo():
...     try:
...             sys.stdin.read()
...     except KeyboardInterrupt:
...             print "BLAH"
...
>>> foo()

这会在按下 CTRL+C 后立即返回。当我立即尝试再次调用 foo 时，发生了有趣的事情:

>>> foo()

Traceback (most recent call last):
  File "c:\Python26\lib\encodings\cp437.py", line 14, in decode
    def decode(self,input,errors='strict'):
KeyboardInterrupt

在我没有按 CTRL+C 的情况下立即引发了异常。

这似乎是有道理的——我们似乎正在处理 Python 中如何处理异步异常的细微差别。在实际弹出异步异常然后在当前执行上下文中引发之前，它可能需要几个字节码指令。 (这是我过去玩它时看到的行为)

参见 C API:http://docs.python.org/c-api/init.html#PyThreadState_SetAsyncExc

所以这在一定程度上解释了为什么在这个示例中执行 finally 语句的上下文中会引发 KeyboardInterrupt:

>>> def foo():
...     try:
...             sys.stdin.read()
...     except KeyboardInterrupt:
...             print "interrupt"
...     finally:
...             print "FINALLY"
...
>>> foo()
FINALLY
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 7, in foo
KeyboardInterrupt

自定义信号处理程序与解释器的标准 KeyboardInterrupt/CTRL+C 处理程序混合在一起可能会导致这种行为。例如， read() 调用看到信号并退出，但它在取消注册它的处理程序后重新引发信号。如果不检查解释器代码库，我无法确定。

这就是为什么我通常回避使用异步异常......

编辑 2

我认为有一个很好的错误报告案例。

再次更多的理论...(仅基于阅读代码)查看文件对象源:http://svn.python.org/view/python/branches/release26-maint/Objects/fileobject.c?revision=81277&view=markup

file_read 调用 Py_UniversalNewlineFread()。 fread 可以使用 errno = EINTR 返回错误(它执行自己的信号处理)。在这种情况下 Py_UniversalNewlineFread() 保释但不使用 PyErr_CheckSignals() 执行任何信号检查，以便可以同步调用处理程序。 file_read 清除文件错误但也不调用 PyErr_CheckSignals()。

请参阅 getline() 和 getline_via_fgets() 以了解如何使用它的示例。该模式在此错误报告中记录了类似问题:(http://bugs.python.org/issue1195)。因此，解释器似乎在不确定的时间处理了信号。

我想深入研究没有什么值(value)，因为仍然不清楚 sys.stdin.read() 示例是否是您的“dostuff()”函数的适当模拟。 (可能有多个错误在起作用)