This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] MI error messages
Eli Zaretskii writes:
> > 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 don't care much, but isn't mi-common.c a better place?
mi-common.c seems a bit of a misnomer. Perhap common here means frequent
rather than shared. mi-common.h isn't included in any of the c files apart
from mi-common.c
> > I think it would be better to call it something like mi_usage_error
>
> I have no problem with mi_usage_error.
>
> > 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.
>
> Yes. And that is why they should go through `error', not through
> `mi_usage_error'.
I presumed mi_usage_error would call error. That way the error is caught and
any cleanups and rewinds are done. However, you are right, it would be nicer
just to get:
(gdb)
-stack-select-frame
Usage: FRAME_SPEC.
(gdb)
instead of
(gdb)
-stack-select-frame
&"Usage: -stack-select-frame FRAME_SPEC\n"
^error,msg="Usage: -stack-select-frame FRAME_SPEC"
(gdb)
as these errors aren't intended for the user when the frontend is being used.
> > Perhaps they should be made more transparent.
>
> I guess you mean ``more self-explanatory''. Yes, I agree. One way of
> doing that is not to hide relevant context information that is
> available at the locus of the error message; in this case, that
> context is the name of the object. Thus,
>
> Variable object `warranty' not found.
>
> is IMHO much better, even though your suggestion is an additional
> improvement.
I'll look at submitting a revised patch for mi-cmd-stack.c and mi-cmd-var.c
Nick