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: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: tromey at redhat dot com, gdb-patches at sources dot redhat dot com
- Date: Mon, 04 Aug 2008 06:20:47 +0300
- Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support
- References: <20080528205921.GA2969@caradoc.them.org> <20080615181833.uxmo25mg0kko40kw@imap.linux.ibm.com> <1216107418.14956.27.camel@localhost.localdomain> <m3od4z3w0t.fsf@fleche.redhat.com> <m3k5fl3ncy.fsf@fleche.redhat.com> <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>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> Cc: tromey@redhat.com, gdb-patches@sources.redhat.com
> Date: Sun, 03 Aug 2008 23:50:43 -0300
>
> > When executing the @code{python} command, Python exceptions uncaught
> > within the Python code are translated to calls to @value{GDBN}
> > error-reporting mechanism, which terminates the currently executing
> > command and prints 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:
>
> ... it is not necessarily true that GDB will terminate the currently
> executing command when the Python exception is converted to a GDB
> exception. If the Python script is extending some GDB subsystem (one of
> our goals), that subsystem can catch the exception and deal with it in
> another way. So for this part I suggest:
>
> ... are translated to calls to @value{GDBN} error-handling mechanism,
> which depending on the context of the Python script can either deal
> with the error in a subsystem-specific way, or terminate the currently
> executing command ...
>
> What do you think?
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?