Re: [RFA] Fix regression in "commands"

[Pedro Alves <palves@redhat.com>]

On 12/01/2017 04:45 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> Hmm, for the truly "no breakpoints specified" case, 
> Pedro> it seems to me that before we can reach this error, we've already
> Pedro> hit the error at the top of map_breakpoint_numbers:
> Pedro>   if (args == 0 || *args == '\0')
> Pedro>     error_no_arg (_("one or more breakpoint numbers"));
> Pedro> and for the case where the user specifies some argument
> Pedro> that doesn't match any breakpoint, map_breakpoint_numbers
> Pedro> already printed one of:
> Pedro>     warning (_("bad breakpoint number at or near '%s'"), p);
> Pedro>     printf_unfiltered (_("No breakpoint number %d.\n"), num);
> Pedro> when the "No breakpoints specified." error is reached.
> 
> I think the problem is that if the error call is removed from
> commands_command_1, then a failure here won't throw at all, because
> map_breakpoint_number_range just prints a message (either with warning
> or printf_unfiltered -- not sure why the discrepancy), and doesn't
> throw.
> 
> But, this would mean that an script erroneously using "commands" would
> not be interrupted, which seems like maybe a bad result.  Though, as you
> point out, "delete" doesn't do this, so maybe it is ok?

I think it's OK in the principle that "delete", "disable", etc.
which seem like used-more-frequently commands, don't do this.
I think that if we want to error out, then we should do that
to all the commands that take command lists/ranges, and then
maybe do it directly in map_breakpoint_number_range, perhaps.
But I'd start with making "commands" not-error like the
others.

> 
> Making map_breakpoint_number_range throw would mean that the case where
> you have breakpoint 2 and do "commands 1-3" would now fail -- although
> that's worked with a warning since ranges were added.

Right, doesn't seem very friently to make those error out.

Thanks,
Pedro Alves