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

[Daniel Jacobowitz <drow@false.org>]

On Tue, Aug 05, 2008 at 09:10:04PM +0300, Eli Zaretskii wrote:
> > 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
> > > 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?

Your comment about terminating a command if something other than a
command invoked Python.  We terminate whatever it was that invoked
Python.  Operation is a general term ("we're doing something"), which
does not have the risk associated with "command" which has a specific
meaning in GDB.  None of this is restricted to the context of
commands.

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

I'm afraid you've lost me :-(  I need a little help - what's not
right about it?  You said it was confusing, not that it was wrong,
so I tried to make it clearer.

To the best of my technical and writing ability, the version above
accurately describes GDB's behavior.  And I think it's clear, too.

To reduce quoting depth (I have trouble following discussion when it
gets too deep), here it is again.

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

-- 
Daniel Jacobowitz
CodeSourcery