This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]