This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients THRlWiTi, asvetlov, jimbo1qaz, markroseman, roger.serwy, terry.reedy
Date 2015-11-21.05:03:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
(I was wrong about seeing the exception when closing the shell.)

A major difference between [Quit] and [x] is that [Quit] stops the running program whereas [x] closes the visible gui but leaves the program to run through to the end, as though the [go] button were pressed.  I added 'as e' and 'print(e)' to the try except and there are multiple RuntimeErrors, 1 per line traced by [step], including IDLE code for input() and print() calls, with [x], but none with [quit] first.

The TclError only occurs in 3.4.3, not in 2.7.10.

The string 'gui_adapter' comes from, line 28.
  gui_adap_oid = "gui_adapter"
It represents the debugger window in the idle process.  My interpretation of the traceback is that when
  self.gui.interaction(message, frame)
is executed in the user process, the interaction call actually calls debugger.interaction in the idle process via RemoteDebugger.GUIProxy.interaction.  The latter does not appear in the traceback because IDLE rpc calls are deleted from tracebacks before they are printed.

Replacing self.abort_loop with self.quit (which calls abort_loop) eliminates the Runtime exceptions, as the backend debugger in the user process is stopped before the idle process frontend gui disappears.

However, self.idb.set_quit (within self.quit) raises 
  AttributeError: 'Idb' object has no attribute 'botframe'
if one attempts to immediately close the debugger window (with menu or button) before it is activated.  It is then left as a zombie window. The exception is in the Tkinter callback, so it is printed to console rather than the IDLE shell, and included RemoteDebugger and rpc calls, but not the line in Bdb.set_quit(self), 
        self.stopframe = self.botframe
that actually raised the exception.  So the call must either be conditioned or the exception caught.  I decided to go with latter now.
Date User Action Args
2015-11-21 05:03:37terry.reedysetrecipients: + terry.reedy, roger.serwy, asvetlov, markroseman, THRlWiTi, jimbo1qaz
2015-11-21 05:03:37terry.reedysetmessageid: <>
2015-11-21 05:03:37terry.reedylinkissue15348 messages
2015-11-21 05:03:36terry.reedycreate