Re: [RFC][gdb/cli] Ignore error in gdb command script

[Philippe Waroquiers via Gdb-patches <gdb-patches@sourceware.org>]

On Tue, 2021-05-18 at 23:59 +0200, Tom de Vries wrote:
> On 5/18/21 9:16 PM, Philippe Waroquiers wrote:
> > 
> > On Tue, 2021-05-18 at 17:16 +0200, Tom de Vries wrote:
> > > On 5/18/21 4:42 PM, Tom Tromey wrote:
> > > > > > > > > "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
> > > > 
> > > > Simon> That sounds useful.  I think that "ignore-errors" is a good initial
> > > > Simon> name, because it's clear and self-describing.  We can always find and
> > > > Simon> add a short alias later.
> > > > 
> > > > Fedora has shipped a Python implementation of exactly this for a while now.
> > > > So, +1 for this name and approach from me.
> > > > 
> > > > One question is whether it should catch 'quit'.  I tend to think not but
> > > > it should be considered.
> > > > 
> > > > There is some other prior art too:
> > > > 
> > > >     https://sourceware.org/bugzilla/show_bug.cgi?id=8487
> > > > 
> > > > ignore-errors covers all the uses I've ever wanted personally, though,
> > > > so I think it would be fine to just go with that.  However if someone is
> > > > feeling more maximal, try-catch would also be an ok addition.
> > > 
> > > [ Thanks all for the feedback.  Replying to latest email, CC-ing Andrew. ]
> > > 
> > > Changes:
> > > - now a proper command
> > Instead of adding an ignore-errors command, an alternative could be to implement
> > this via a new GDB setting 'set ignore-errors on|off'.
> > 
> > This allows to do e.g.
> >   with ignore-errors on -- some-command
> > or (shorter form): 
> >   with ignore-errors -- some-command
> > or when needed
> >   with ignore-errors off -- some-command
> > 
> > This also allows to use
> >   set ignore-errors on
> >   ...
> > at the beginning of a script and/or in .gdbinit 
> >   and/or as a -ex 'set ignore-errors on' gdb startup arg.
> > 
> > 
> > Also, an alias can be defined such as:
> >   alias ie = with ignore-errors on --
> > 
> 
> Hi Philippe,
> 
> good ideas, I'd say, but for now I just want to do the basic
> functionality as it has been available and used for some time.
> 
> This could be implemented as follow-up patch, and I don't see a problem
> with that approach.

Not too sure to understand what is meant by 'follow-up' patch as the approaches
are not really aligned:  implementing the 'setting approach' later will then add
a different way rather than extend this one.

For what concerns the naming of the ignore-errors command (discussed in another mail
e.g. as it it makes 'ignore' abbreviations ambiguous): it is worth
mentioning that 'thread apply' and 'frame apply' have -c and -s
arguments to indicate respectively  'print any error and continue'
and 'silently ignore any error'.

So, maybe the naming of the new setting could be
  set error-handling [abort-execution|print-and-continue|silently-ignore]
(default value abort-execution).

If the 'setting approach' is  not the initial absolutely to do preferred approach :),
then the command could be:
   error-handle [-a|-c|-s] [--]  COMMAND
(with -c being the default if no flag specified).

Thanks

Philippe