Re: cleanup mi error message handling

[Nick Roberts <nickrob@snap.net.nz>]

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

-- 
Nick                                           http://www.inet.net.nz/~nickrob