为什么我无法在 python 中处理键盘中断？

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: 子句也没有运行。

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

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

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

但这是有效的：

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

这是打印的内容：

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

因此，出于某种原因，“完成阅读”。即使异常发生在上一行，也会打印该行。这并不是真正的问题 - 显然我必须能够处理“try”块内任何地方的异常。但是，打印无法正常工作 - 它不会像预期的那样打印换行符！ “Interruped”打印在同一行...前面有一个空格，出于某种原因...？不管怎样，之后代码就完成了它应该做的事情。

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

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

编辑：

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

>>> 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

：自定义信号处理程序与解释器的标准键盘中断/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）。因此，信号似乎是由解释器在不确定的时间处理的。

我想深入研究没有什么价值，因为仍然不清楚 sys.stdin.read() 示例是否是“dostuff()”函数的正确模拟。 （可能存在多个错误）

Answer 2

sys.stdin.read() 是一个系统调用，因此每个系统的行为都会有所不同。对于 Windows 7，我认为发生的情况是输入正在被缓冲，因此您将得到 sys.stdin.read() 将所有内容返回到 Ctrl-C 并且一旦您再次访问 sys.stdin 它将发送“Ctrl-C”。

尝试以下操作，

def foo():
    try:
        print sys.stdin.read()
        print sys.stdin.closed
    except KeyboardInterrupt:
        print "Interrupted!"

这表明正在进行 stdin 缓冲，导致再次调用 stdin 来识别键盘输入，

def foo():
    try:
        x=0
        while 1:
            x += 1
        print x
    except KeyboardInterrupt:
        print "Interrupted!"

这似乎没有问题。

dostuff() 是否从标准输入读取？

Answer 3

遇到类似的问题，这是我的解决方法：

try:
    some_blocking_io_here() # CTRL-C to interrupt
except:
    try:
        print() # any i/o will get the second KeyboardInterrupt here?
    except:
        real_handler_here()

Answer 4

您可以使用装饰器包装函数，以便在 Windows 上处理 KeyboardInterrupt：

def safe_system_call(func):
    """
    Decorator to be used to handle Windows errors when program
    is halted by user termination (CTRL+C).

    Meant to be wrap around functions like {time.sleep}, print and input.
    """

    @wraps(func)
    def wrapper(*args, **kwargs):
        try:
            return func(*args, **kwargs)
        except KeyboardInterrupt:
            sys.exit(-1) # Handle Keyboard Interrupt for system call
    return wrapper

使用

import sys
import time

time.sleep = safe_system_call(time.sleep)
sys.stdin.read = safe_system_call(sys.stdin.read)

_{KeyboardInterrupt 应该开箱即用，因为它在 Linux 中是这样的。这是处理此类错误的解决方法。但它仍然有陷阱。可能很难涵盖代码中的所有系统调用。}

Answer 5

下面是对发生的情况的猜测：

• 按 Ctrl-C 会中断“print”语句（无论出于何种原因...bug？Win32 限制？）
• 按 Ctrl-C 还会引发第一个 KeyboardInterrupt，在 dostuff() 中
• 异常处理程序运行并尝试打印“Interrupted”，但“print”语句被破坏并引发另一个KeyboardInterrupt。
• finally 子句运行并尝试打印“cleaning up....”，但“print”语句被破坏并引发另一个键盘中断。

Answer 6

这对我有用：

import sys

if __name__ == "__main__":
    try:
        sys.stdin.read()
        print "Here"
    except KeyboardInterrupt:
        print "Worked"
    except:
        print "Something else"
    finally:
        print "Finally"

尝试在 dostuff() 函数之外放一行，或者将循环条件移到函数之外。例如：

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

Answer 7

def foo():
    try:
        x=0
        while 1:
            x+=1
            print (x)
    except KeyboardInterrupt:
       print ("interrupted!!")
foo()

效果很好。