Re: cleanup mi error message handling

[Vladimir Prus <ghost@cs.msu.su>]

On Monday 31 March 2008 10: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.

The "user input" was not done in the console window. It was done by pressing
some buttons in UI. It makes sense that any feedback to said input is done by
updating UI where the input was made.

 >  > > 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.

As it happens, we already have a patch. 

>  > > If a change has to be made I would suggest the one below.  However this
>  > > would mean going through all the errors reported in MI to work out which
>  > > ones need mi_error_message but currently use error (), e.g.,
>  > > "mi_cmd_stack_list_locals: Usage: PRINT_VALUES".
>  > 
>  > > *** mi-main.c 31 Mar 2008 12:08:10 +1200 1.110
>  > > --- mi-main.c 31 Mar 2008 12:16:01 +1200
>  > > *************** mi_execute_command (char *cmd, int from_
>  > > *** 1260,1278 ****
>  > > ...
>  > >
>  > > Perhaps not quite this but with a ^done RESULT-RECORD too.
>  > 
>  > So, you are suggesting that if execution of MI command results in an call to
>  > 'error', we respond with ^done? That does not appear right to me. Surely, an
>  > exception thrown during processing of a command means we cannot finish that
>  > command, which should be reported to the user.
> 
> The error is still reported, but on the other channel.

So, are you suggesting that the frontend, in order to understand if the command
was successful, goes and parses the "&" channel? First, this will totally break
existing frontends. Second, "^error" is clear statement that an error has occurred.
Parsing "&" to guess if an error was occurred is an ad-hoc solution -- that's how
CLI-based frontends used to work, and that was a total mess.

Notice that the message appears at "&" channel right now only because in MI,
both gdb_stdlog and gdb_stderr map to the same channel. Presumably, it's because
the original author did not see much value in separate error channel. Note also
that messages normally output to the gdb_stdlog are for debugging GDB purposes,
like output of "set debug target 1". Notice that also many use of gdb_stderr
are debugging in the purposes, too -- those are messages that don't abort
the current operation but might be useful, if something goes wrong. So, it's
reasonable to assume that the "&" channel is primarily for logging/debugging
purposes.

Then, sending the error that is already reported via other mechanism to the "&"
channel does not seem necessary.

- Volodya