Re: cleanup mi error message handling

[Pedro Alves <pedro at codesourcery dot com>]

A Monday 31 March 2008 07:35:31, Nick Roberts wrote:
>  > > I can't understand these sentences.  The command -exec-continue won't
>  > > appear in the console but "The program is not being run." will.
>  >
>  > And what is the possible value of that message to the user? It does not
>  > correspond to anything user has typed in, and it does not correspond to
>  > anything user sees.  It's just a message out of blue sky.
>
> It's not out of the blue, it's a consequence of user input, just not typed
> user input.
>
>  > If we want the console to be truly useful, it should accept all commands
>  > from the user, and print GDB responses, including errors, to those
>  > commands. Printing responses to commands implicitly emitted by the
>  > frontend does not seem to be the purpose of the console window.
>
> I think it's useful.
>
>  > > These `errors' and other similar ones like "No stack." are reported
>  > > through error () and are normal Gdb output for the user to see. 
>  > > Currently the console can display such messages by reading
>  > > LOG-STREAM-OUTPUT.
>  > >
>  > > Other errors like:
>  > >
>  > > (gdb)
>  > > -interpreter-exec
>  > > ^error,msg="mi_cmd_interpreter_exec: Usage: -interpreter-exec interp
>  > > command" (gdb)
>  > >
>  > > would be due to a frontend error, so I think it would be probably be
>  > > best to display them elsewhare, e.g., status bar.
>  >
>  > No proposal to change the ^error is made.
>
> No, but you can't distinguish between the errors with only one channel.
>
>  > > The only way for the frontend to distinguish between the two types of
>  > > error is if the Gdb developer uses the appropriate mechanism, i.e.
>  > > error () or mi_error_message in each case.
>  > >
>  > > I wouldn't make any changes until a real problem is reported (not just
>  > > Pedro tidying things up).
>  >
>  > You make it sound as if code cleanup is something on N-th priority. I
>  > don't think it's so, it's one of the most important things in current
>  > GDB, and it also allows us to identify nonobvious behaviour, such as
>  > happened here.
>
> My point is that since the code may be of value (the author has gone to
> some trouble to create two error channels) and as it's not causing much
> inconvenience it's best to leave things as they are for the moment.  I
> could give a long list of things that are more important to work on.
>

If we want to distinguish them, the correct form is to encode it in the 
exception itself.  We can add a new MI_GENERIC_ERROR to "enum errors",
and come up with a new mi_error function that throws that error class
instead of GENERIC_ERROR.  Then we can catch those instead of
handling MI_CMD_ERROR in a pass-error-code-in-return-of-function style.

In fact, my first approach went this path.  I then reverted that into
using generic `error' when I couldn't come up with a valid use for
having some cases output to stderr, and others not.  I've ended up
making everything go to ^error, but if the discussion ends up deciding
things should go to stderr too, I still didn't see a convincing reason
why *some* responses shouldn't go to stderr.

I know that these errors can only come from the frontend passing
invalid args to gdb, but, how often does that happen, that we need
to make sure the user doesn't see it (in the current form of things).  And
if the frontend is failing to coordinate with gdb, why do we go
to great lengths to not tell the user looking at the console?  I'm
not advocating to put things on stderr -- heck, I was the one proposing
not to, I just trying to understand why *you* think that *some* errors,
which normally should *never* happen, should be given *special* treatment.
Honest, I'd like to know that.

-- 
Pedro Alves