command error handling

[jtc at redback dot com (J.T. Conklin)]

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?

        --jtc

-- 
J.T. Conklin
RedBack Networks