Re: MI error msgs and localization

[Bob Rossi <bob@brasko.net>]

On Tue, Feb 14, 2006 at 04:05:05PM -0500, Daniel Jacobowitz wrote:
> On Wed, Feb 15, 2006 at 09:58:23AM +1300, Nick Roberts wrote:
> >  > I don't particular like to hard-code these strings. The list of messages I 
> >  > gave previously are all marked as console-stream-output. What I am saying is 
> >  > that localizing such error messages will hurt MI dependant tools since the 
> >  > messages are highly useful for the front-end. I'm not sure what purpose 
> >  > console-output really has in a Machine Interface as it tends to make sense 
> >  > only to humans - but I guess some systems are making use of them.
> >  > 
> >  > What I'd really like is to see them also wrapped in result-records (sample; 
> >  > ignore syntax):
> >  > 
> >  > ^failed,type="init-option-unrecognized",msg="Unrecognized option"
> >  > 
> >  > Does that make any sense?
> > 
> > We've already got ^error as a result field so it doesn't make any sense to me,
> >  and if "Unrecognized option" comes from the console stream then I think that
> >  can still change.  The problem seems to be that of handling CLI error output
> >  in MI.  I see that the standard GNU error function provides for an error
> >  number which is less likely to change:
> > 
> >  -- Function: void error (int STATUS, int ERRNUM, const char *FORMAT,
> >           ...)
> > 
> > I wonder if GDB's error function could have one for MI e.g
> > 
> > &"Unrecognized option\n"
> > ^error,msg="Unrecognized option",code="35"
> > 
> > or even
> > 
> > &"Unrecognized option\n"
> > ^error,code="35"
> > 
> >  instead of just:
> > 
> > &"Unrecognized option\n"
> > ^error,msg="Unrecognized option"
> 
> GCC developers spent a lot of time talking about this.  I think the
> trick to doing this right is actually to do it the way Bjarke
> suggested: msg= as a free-form, explanatory text, and type= (or code=,
> or something else) as a documented identifier.  But using numbers for
> the identifiers is not necessarily a good idea, because keeping track
> of them is error-prone.  I'd suggest that
> type="init-option-unrecognized" was a lot more memorable than
> "code=35".

I could not agree more here. I think every single error message has to
have a corresponding reason that the FE can understand. For instance, if
the FE is parsing the error message currently generated, it should be
prepared that the message can change at any given time. Any parsing of
the error message is a bad idea. It's as bad as parsing the CLI output.

The only way that MI should pass an error status back to the FE is
through a type="init-option-unrecognized". Each of these error responses
should be documented just like the asynchronous response reasons.

This is the only way to go, IMO.

Bob Rossi