except block isn't catching exception

Cameron Simpson cs at zip.com.au
Sat Aug 8 10:11:48 CEST 2015


On 08Aug2015 17:08, Chris Angelico <rosuav at gmail.com> wrote:
>On Sat, Aug 8, 2015 at 4:56 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> On Fri, Aug 7, 2015 at 8:44 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>> The exception isn't happening inside sock.accept(), as I explained. So
>>> you can't catch it there.
>>
>> Where does the exception happen then? Your explanation only covered
>> why the blocking call cannot be interrupted by it, not why the
>> exception isn't simply raised when the blocking call finishes.
>
>I'm not sure there's anything in the language spec about it; at least,
>I can't find it. But the last time I was digging in the Python/C API,
>there was a caveat that KeyboardInterrupt was raised *at some point
>after* Ctrl-C was hit - a flag gets set, and after every N bytecode
>instructions, the flag is checked, and then the signal gets raised. It
>might happen on only some platforms, and I can't even find back the
>page I was looking at when I read that. Maybe someone else knows?

From:

  https://docs.python.org/3/library/signal.html#execution-of-python-signal-handlers

we have:

  A Python signal handler does not get executed inside the low-level (C) signal 
  handler. Instead, the low-level signal handler sets a flag which tells the 
  virtual machine to execute the corresponding Python signal handler at a later 
  point(for example at the next bytecode instruction).

and in the next section "Signals and threads" it says:

   Python signal handlers are always executed in the main Python thread, even 
   if the signal was received in another thread.

Cheers,
Cameron Simpson <cs at zip.com.au>

Meddle not in the affairs of dragons,
for you are crunchy and good with ketchup.


More information about the Python-list mailing list