Re: [PATCH] MI error messages

Nick Roberts
2005-06-21T09:40:26Z

> Andreas suggested one way to do this. But I think it would be better
> to add a function called, say, mi_error, that would do
>
> error (_("Usage: %s."), msg);
>
> where `msg' is a char * string passed as its argument, and then
> replace each call to `error' with a call to `mi_error', like so:
>
> mi_error ("-stack-list-locals PRINT_VALUES");
>
> The advantage of this is that "Usage: %s" is not repeated dozens of
> times in the message catalog and in the program.

Which file should mi_error/mi_usage_error go in? mi-cmds.c seems the best
option to me as the mi-cmd-*.c files include mi-cmds.h.

I think it would be better to call it something like mi_usage_error, as there
are many other errors generated in MI e.g.

error (_("mi_cmd_var_delete: Variable object not found."));

which, I guess should just be:

error (_("Variable object not found."));

However, unlike the usage error messages which should only be seen by the
person writing the frontend, these messages _will_ be seen by the user.
Perhaps they should be made more transparent. For example, if I inadvertantly
selected the word warranty before clicking on the tool bar to create a watch
expression. The frontend would send:

-var-create - * warranty

GDB would reply:

&"mi_cmd_var_create: unable to create variable object\n"
^error,msg="mi_cmd_var_create: unable to create variable object"

which the frontend could parse, but a more helpful message would be:

"No symbol warranty in current context."

> > Also, in mi-cmd-stack.c, I've given get_selected_frame the message string
> > "No stack." but presumably this also gets translated so should it be:
> >
> > get_selected_frame (_("No stack.")) ?
>
> Yes.

OK

> > Some error messages are terminated with a period, others aren't. I don't
> > know which style is preferred but clearly it would be best to just use
> > one.
>
> They should all end with a period, I think.

OK

Nick