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


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


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