<type>documentation</type>
<domain>trouble</domain>
<id>trouble-debug-nostop-exceptions</id>
<title>Failure to Stop on Exceptions</title>
<date>$Date$</date>
<version>$Revision$</version>
<product>per+</product>

Failure to stop on exceptions is most commonly caused by the same factors that cause
`failure to stop on breakpoints <ref:install/trouble-debug-nostop-breakpoints>`__,
although in this case the debugger may stop but fail to show the source code. 

Another factor in debugging exceptions is that they may be handled by a catch-all
exception handler. Wing doesn't stop on these unless they also print the exception.

The simple work-around for this is to set a breakpoint in the exception handler.

An alternative is to recode your app by adding the following code to catch-all
exception handlers:

.. python::

  import os, sys
  if 'WINGDB_ACTIVE' in os.environ:
    sys.excepthook(*sys.exc_info())

The above only works with ``When Printed`` exception handling mode, as set by the
`Debugger > Exceptions > Report Exceptions
<script:show_preferences_gui#prefname="debug.exception-mode">`__ preference).

The following variant can be used with other exception handling modes:

.. python::

  import os

  # No handler when running in Wing's debugger
  if 'WINGDB_ACTIVE' in os.environ:
    dosomething()

  # Handle unexpected exceptions gracefully at other times
  else:
    try:
      dosomething()
    except:
      # handler here
      
Note that environments such as wxPython, PyGTK, and others include catch-all
handlers for unexpected exceptions raised in the main loop, but those handlers
cause the exception traceback to be printed and thus will be reported correctly
by Wing without any modification to the handler.

