Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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));


  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