Re: command error handling

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> The CLI for the memory region attributes feature I'm working on is
> based on displays.  Each memory region created is assigned a number,
> and can be enabled, disabled, and deleted.
> 
> While stealing the display CLI code, I noticed that when you enable or
> disable a non-extant display, a message will be output with printf_-
> unfiltered(), but when you do the same thing with delete, GDB calls
> error().  The same thing occurs when you attempt to enable/disable/
> delete displays with a non-numeric argument.  I'll argue that delete
> should behave like enable and disable, that a message be output and
> execution should continue.
> 
> The problem with error(), IMHO, is that it's very heavy handed.  While
> it allows us to avoid the fun of propagating errors up from the lowest
> levels of GDB, it also makes it impossible for user defined functions
> to detect the failure of a command (that, plus the fact that there are
> no command return values, but that's easily remedied by comparision).
> Without such a mechanism, the usefulness of scripting is greatly
> diminished.  I would expect it to much be the same for all extension
> languages that may be bound into GDB.
> 
> Is this a (long-term) direction we should be investigating?

The consensus last time this was discussed was that code should cleanly
unwind the stack stack rather than calling error().

Unfortunatly, eliminating error calls in general is really slow and
hard.  Even once that is done, there is internal_error() to contend with
:-)

What people have been doing instead is wrapping calls into GDB so that
they always return.  The hope is that later, someone else will eliminate
the need for the actual wrapper.

	Andrew