From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21534 invoked by alias); 12 Feb 2006 09:22:32 -0000 Received: (qmail 21519 invoked by uid 22791); 12 Feb 2006 09:22:31 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 12 Feb 2006 09:22:29 +0000 Received: from kahikatea.snap.net.nz (p202-124-115-73.snap.net.nz [202.124.115.73]) by viper.snap.net.nz (Postfix) with ESMTP id 88481744DAB; Sun, 12 Feb 2006 22:22:18 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 535078887; Sun, 12 Feb 2006 22:21:22 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17390.65041.325032.659975@kahikatea.snap.net.nz> Date: Sun, 12 Feb 2006 09:22:00 -0000 To: Jim Blandy Cc: Mark Kettenis , eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: MI error messages In-Reply-To: <8f2776cb0602112349y6d7387b3v76df00d9505fc2fd@mail.gmail.com> References: <20060210134700.GA21328@nevyn.them.org> <200602102034.k1AKYtI4023423@elgar.sibelius.xs4all.nl> <8f2776cb0602112349y6d7387b3v76df00d9505fc2fd@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00118.txt.bz2 Jim Blandy writes: > On 2/10/06, Mark Kettenis 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 * 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));