Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 4 Aug 2008 08:14:52 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>, tromey@redhat.com, 	gdb-patches@sources.redhat.com
> 
> On Mon, Aug 04, 2008 at 06:20:47AM +0300, Eli Zaretskii wrote:
> > I think what I suggested is still valid: no matter how the exception
> > is caught, it will still terminate the current command, won't it?
> > And, btw, do we actually have examples of such non-default exception
> > handling in GDB?
> 
> About half the times that TRY_CATCH or catch_exception / catch_error
> are used, we handle an exception in a more specific way.  Some are for
> cleanups, but many continue after e.g. a memory read error.  The
> current action is terminated, but the action may be just part of
> a command.

Okay, how about this, then:

   When executing the @code{python} command, Python exceptions
   uncaught within the Python code are translated to calls to
   @value{GDBN} error-reporting mechanism.  If the command that called
   @code{python} does not handle the error, @value{GDBN} will
   terminate it and print an error message containing the Python
   exception name, the associated value, and the Python call stack
   backtrace at the point where the exception was raised.  Example: