This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: bauerman at br dot ibm dot com, tromey at redhat dot com, gdb-patches at sources dot redhat dot com
- Date: Mon, 04 Aug 2008 22:48:46 +0300
- Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support
- References: <1216245620.12209.18.camel@localhost.localdomain> <20080718195010.GA14356@caradoc.them.org> <1216653969.31797.6.camel@localhost.localdomain> <uwsj84wx5.fsf@gnu.org> <m3prp0efvr.fsf@fleche.redhat.com> <20080726173508.GA16470@caradoc.them.org> <m363qsee4r.fsf@fleche.redhat.com> <uej5g4frg.fsf@gnu.org> <1217818243.9336.7.camel@localhost.localdomain> <uhca1lb3k.fsf@gnu.org> <20080804121451.GA13640@caradoc.them.org>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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: