From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31584 invoked by alias); 13 Feb 2006 07:05:59 -0000 Received: (qmail 31574 invoked by uid 22791); 13 Feb 2006 07:05:58 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 13 Feb 2006 07:05:57 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1F8XmU-0002tY-2Z for gdb@sources.redhat.com; Mon, 13 Feb 2006 10:05:54 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1F8XmM-0002tJ-GO; Mon, 13 Feb 2006 10:05:46 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: MI error messages Date: Mon, 13 Feb 2006 07:05:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: <17388.62632.330005.663964@kahikatea.snap.net.nz> In-Reply-To: <17388.62632.330005.663964@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602131005.45774.ghost@cs.msu.su> 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/msg00121.txt.bz2 On Friday 10 February 2006 23:16, Nick Roberts wrote: > > Below is a short MI session: > > > > (gdb) -var-assign KDEVTMP br > > &"mi_cmd_var_assign: Could not assign expression to varible > > object\n" ^error,msg="mi_cmd_var_assign: Could not assign expression to > > varible > > > > The good thing about this is that I can easily detect that's an error, > > and show a message to the user. The bad thing is that the message > > includes 'mi_cmd_var_assign:' part. For end user of KDevelop, or even > > end user of gdb, this makes no sense -- it's the name of internal > > function. It can only confuse. > > In June of last year there was a thread ([PATCH] MI error messages) about > this subject (see archives). I think it was similarly suggested that the > procedure name was unnecessary. Some error messages are for the user, and > some should only occur if there is a bug in the front end and should never > really be seen by the user. The example you give above is the latter. I believe you're wrong. The example I given actually results from situation where user specifies a wrong new value for a variable. The specific testcase I've tried in KDevelop is assigning value of "br" to "int" variable. That's clearly a user error. > > 3. If not, can the function name be removed? > > I think error reporting needs to be overhauled. Many changes could be > made, removing function names is one of them. Ok. I'll try to find time to remove some of function names. - Volodya