Почему я не могу обработать KeyboardInterrupt в python?

К сожалению, асинхронная обработка исключений ненадежна (исключения, вызванные обработчиками сигналов, вне контекста через C API и т. д.). Вы можете увеличить свои шансы на правильную обработку асинхронного исключения, если в коде есть некоторая координация того, какой фрагмент кода отвечает за их перехват (максимально возможный уровень в стеке вызовов кажется подходящим, за исключением очень важных функций).

Вызываемая функция (dostuff) или функции, расположенные дальше по стеку, могут сами иметь перехват для KeyboardInterrupt или BaseException, который вы не учли/не смогли учесть.

Этот тривиальный случай отлично работал с Python 2.6.6 (x64) интерактивный + Windows 7 (64-битная):

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

Так что это в некоторой степени объясняет, почему KeyboardInterrupt вызывается в контексте выполнения оператора finally в этом примере:

>>> 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?ревизия=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() — это системный вызов, поэтому поведение будет отличаться для каждой системы. Для Windows 7 я думаю, что происходит то, что ввод буферизуется, и поэтому вы получаете, где sys.stdin.read() возвращает все до Ctrl-C, и как только вы снова получите доступ к sys.stdin, он отправит «Ctrl- С".

попробуйте следующее,

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() читает со стандартного ввода?

Имея аналогичную проблему, и это мой обходной путь:

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

Вот предположение о том, что происходит:

• нажатие Ctrl-C прерывает оператор "print" (по какой-то причине... ошибка? Ограничение Win32?)
• нажатие Ctrl-C также вызывает первый KeyboardInterrupt в dostuff()
• Обработчик исключений запускается и пытается напечатать «Прервано», но оператор «печать» не работает и вызывает еще один прерывание клавиатуры.
• Предложение finally запускается и пытается напечатать «очистка…», но оператор «print» не работает и вызывает еще один прерывание клавиатуры.

Это работает для меня:

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

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

Это прекрасно работает.