From: Nick Roberts <nickrob@snap.net.nz>
To: Jim Blandy <jimb@red-bean.com>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,
eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com,
gdb-patches@sources.redhat.com
Subject: Re: MI error messages
Date: Sun, 12 Feb 2006 09:22:00 -0000 [thread overview]
Message-ID: <17390.65041.325032.659975@kahikatea.snap.net.nz> (raw)
In-Reply-To: <8f2776cb0602112349y6d7387b3v76df00d9505fc2fd@mail.gmail.com>
Jim Blandy writes:
> On 2/10/06, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > The only way we can ever be consistent is by removing them. Function
> > names are an implementation detail. What if we reorganize the code a
> > bit, changing the function name. Should we change the error message?
> > Or leave it as is, such that it no longer refers to the function that
> > actually prints that message?
>
> I think this is right. These GDB function names have no place in a protocol.
Last year I suggested changing messages like:
mi_cmd_var_create: Usage: NAME FRAME EXPRESSION.
to
Usage: -var-create NAME FRAME EXPRESSION
I got some agreement but lost my way with other detail.
If the frontend is working properly then the user shouldn't see most of these
messages, but it may help frontend writers who don't want to look at the
internals of GDB.
In practice, I've only found a problem with one error message, which does
get seen by the user and which I described at the time:
...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.\n"
^error,msg="No symbol warranty in current context."
This is orthogonal to the general discussion and, IMHO, a clear improvement.
Shall I commit it?
Nick
2006-02-12 Nick Roberts <nickrob@snap.net.nz>
* mi/mi-cmd-var.c (mi_cmd_var_create): Use an error message that
is meaningful to the user.
*** mi-cmd-var.c 05 Jan 2006 10:56:18 +1300 1.23
--- mi-cmd-var.c 12 Feb 2006 21:55:07 +1300
***************
*** 96,102 ****
var = varobj_create (name, expr, frameaddr, var_type);
if (var == NULL)
! error (_("mi_cmd_var_create: unable to create variable object"));
ui_out_field_string (uiout, "name", name);
ui_out_field_int (uiout, "numchild", varobj_get_num_children (var));
--- 96,102 ----
var = varobj_create (name, expr, frameaddr, var_type);
if (var == NULL)
! error (_("No symbol %s in current context."), expr);
ui_out_field_string (uiout, "name", name);
ui_out_field_int (uiout, "numchild", varobj_get_num_children (var));
next prev parent reply other threads:[~2006-02-12 9:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-10 11:36 Vladimir Prus
2006-02-10 11:54 ` Eli Zaretskii
2006-02-10 13:47 ` Daniel Jacobowitz
2006-02-10 14:03 ` Vladimir Prus
2006-02-10 15:00 ` Daniel Jacobowitz
2006-02-10 20:31 ` Mark Kettenis
2006-02-10 15:22 ` Eli Zaretskii
2006-02-10 15:26 ` Daniel Jacobowitz
2006-02-10 15:45 ` Eli Zaretskii
2006-02-10 20:35 ` Mark Kettenis
2006-02-12 7:49 ` Jim Blandy
2006-02-12 9:22 ` Nick Roberts [this message]
2006-02-10 20:17 ` Nick Roberts
2006-02-13 7:05 ` Vladimir Prus
2006-02-13 7:43 ` Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17390.65041.325032.659975@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
--cc=jimb@red-bean.com \
--cc=mark.kettenis@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox