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

[Eli Zaretskii]

> Date: Tue, 5 Aug 2008 08:19:08 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com
> 
> On Tue, Aug 05, 2008 at 06:30:51AM +0300, Eli Zaretskii wrote:
> > > So that gives me a paragraph like this, which I think is accurate.
> > > Does this look OK to you?
> > > 
> > >   When executing Python code, uncaught Python exceptions are translated
> > >   to calls to the @value{GDBN} error-reporting mechanism.  If
> > >   @value{GDBN} does not handle the error, it will terminate the current
> > >   command 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:
> > 
> > I'm not sure this change is for the best: you've eliminated only one
> > of the two uses of "command" in this text, which just obfuscates the
> > text a little (what is it exactly in GDB that does not handle the
> > error, and if it isn't a command that invoked "python", why do we
> > terminate a command?).
> 
> Is s/command/operation/ acceptable?

No objections, but what problem would that solve?

> If any part of GDB handles the error, the error is swallowed.
> Otherwise it drifts upwards through the call stack, terminating
> function calls as it goes.  It's always caught if it reaches the main
> command loop, but there are lots of other places too.

Yes, I know, but again: how does this help to make the above passage
right?