This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] MI error messages


> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Tue, 21 Jun 2005 21:40:38 +1200
> Cc: gdb-patches@sources.redhat.com
> 
> 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?

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]