MI error messages

MI error messages

[Vladimir Prus]

Hello!

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.

So, could somebody tell:

1. Is it guaranteed that all MI error message start with function name and a
semicolon?
2. If not, is there any regexp that can be used to remove the function name,
that's guaranteed to work for all current and future MI error messages.
Removing anything before first semicolon is risky -- error message can
contain ':' for other reasons.
3. If not, can the function name be removed?

- Volodya

Re: MI error messages

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Fri, 10 Feb 2006 14:35:08 +0300
> 
> 1. Is it guaranteed that all MI error message start with function name and a
> semicolon?

I see a small number of error messages that don't, but those are
probably bugs that need to be fixed.

Re: MI error messages

[Daniel Jacobowitz]

On Fri, Feb 10, 2006 at 01:54:08PM +0200, Eli Zaretskii wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Fri, 10 Feb 2006 14:35:08 +0300
> > 
> > 1. Is it guaranteed that all MI error message start with function name and a
> > semicolon?
> 
> I see a small number of error messages that don't, but those are
> probably bugs that need to be fixed.

Really?  Why?  I don't think the function name adds much value in
user-level error messages.  Internal errors, sure.

It is certainly not guaranteed; there's no separation between "MI error
messages" and "other GDB error messages" since an MI session can
reach just about any call to error() in the sources.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI error messages

[Vladimir Prus]

On Friday 10 February 2006 16:47, Daniel Jacobowitz wrote:
> On Fri, Feb 10, 2006 at 01:54:08PM +0200, Eli Zaretskii wrote:
> > > From:  Vladimir Prus <ghost@cs.msu.su>
> > > Date:  Fri, 10 Feb 2006 14:35:08 +0300
> > >
> > > 1. Is it guaranteed that all MI error message start with function name
> > > and a semicolon?
> >
> > I see a small number of error messages that don't, but those are
> > probably bugs that need to be fixed.
>
> Really?  Why?  I don't think the function name adds much value in
> user-level error messages.  Internal errors, sure.

Does it mean that function names should be removed from error messages to 
user?

- Volodya

Re: MI error messages

[Daniel Jacobowitz]

On Fri, Feb 10, 2006 at 05:03:34PM +0300, Vladimir Prus wrote:
> On Friday 10 February 2006 16:47, Daniel Jacobowitz wrote:
> > On Fri, Feb 10, 2006 at 01:54:08PM +0200, Eli Zaretskii wrote:
> > > > From:  Vladimir Prus <ghost@cs.msu.su>
> > > > Date:  Fri, 10 Feb 2006 14:35:08 +0300
> > > >
> > > > 1. Is it guaranteed that all MI error message start with function name
> > > > and a semicolon?
> > >
> > > I see a small number of error messages that don't, but those are
> > > probably bugs that need to be fixed.
> >
> > Really?  Why?  I don't think the function name adds much value in
> > user-level error messages.  Internal errors, sure.
> 
> Does it mean that function names should be removed from error messages to 
> user?

I have no idea.  Personally, I think they should be.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI error messages

[Mark Kettenis]

> X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on 
> 	elgar.sibelius.xs4all.nl
> X-Spam-Level: 
> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=no 
> 	version=3.1.0
> X-From_: gdb-return-24220-m.m.kettenis=alumnus.utwente.nl@sourceware.org  Fri Feb 10 16:00:26 2006
> Date: Fri, 10 Feb 2006 09:59:50 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sources.redhat.com
> Mail-Followup-To: Vladimir Prus <ghost@cs.msu.su>, 	Eli Zaretskii <eliz@gnu.org>, gdb@sources.redhat.com
> Content-Disposition: inline
> X-IsSubscribed: yes
> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
> Sender: gdb-owner@sourceware.org
> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information.
> X-UTwente-MailScanner: Found to be clean
> X-MailScanner-From: gdb-return-24220-m.m.kettenis=alumnus.utwente.nl@sourceware.org
> 
> On Fri, Feb 10, 2006 at 05:03:34PM +0300, Vladimir Prus wrote:
> > On Friday 10 February 2006 16:47, Daniel Jacobowitz wrote:
> > > On Fri, Feb 10, 2006 at 01:54:08PM +0200, Eli Zaretskii wrote:
> > > > > From:  Vladimir Prus <ghost@cs.msu.su>
> > > > > Date:  Fri, 10 Feb 2006 14:35:08 +0300
> > > > >
> > > > > 1. Is it guaranteed that all MI error message start with function name
> > > > > and a semicolon?
> > > >
> > > > I see a small number of error messages that don't, but those are
> > > > probably bugs that need to be fixed.
> > >
> > > Really?  Why?  I don't think the function name adds much value in
> > > user-level error messages.  Internal errors, sure.
> > 
> > Does it mean that function names should be removed from error messages to 
> > user?
> 
> I have no idea.  Personally, I think they should be.

I agree.

Mark

Re: MI error messages

[Eli Zaretskii]

> Date: Fri, 10 Feb 2006 08:47:01 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> On Fri, Feb 10, 2006 at 01:54:08PM +0200, Eli Zaretskii wrote:
> > > From:  Vladimir Prus <ghost@cs.msu.su>
> > > Date:  Fri, 10 Feb 2006 14:35:08 +0300
> > > 
> > > 1. Is it guaranteed that all MI error message start with function name and a
> > > semicolon?
> > 
> > I see a small number of error messages that don't, but those are
> > probably bugs that need to be fixed.
> 
> Really?  Why?

For consistency.

> I don't think the function name adds much value in user-level error
> messages.

MI is not a user-level protocol, it's a machine-level protocol.  What
is displayed to the user as a result is another matter.

> It is certainly not guaranteed; there's no separation between "MI error
> messages" and "other GDB error messages" since an MI session can
> reach just about any call to error() in the sources.

We should either have all or none of the MI messages state the
function.  A machine-oriented interface must be consistent, IMO.

Re: MI error messages

[Daniel Jacobowitz]

On Fri, Feb 10, 2006 at 05:22:31PM +0200, Eli Zaretskii wrote:
> > I don't think the function name adds much value in user-level error
> > messages.
> 
> MI is not a user-level protocol, it's a machine-level protocol.  What
> is displayed to the user as a result is another matter.

These are just the result of calls to error ().  Admittedly, many of
them are for mistakes that a GUI shouldn't be making - but some can
easily come from user input, so when you get one, I don't think you've
got much choice but to display it to the user.

> > It is certainly not guaranteed; there's no separation between "MI error
> > messages" and "other GDB error messages" since an MI session can
> > reach just about any call to error() in the sources.
> 
> We should either have all or none of the MI messages state the
> function.  A machine-oriented interface must be consistent, IMO.

Then they'll have to go unless you want error () to automatically
collect the function (not very useful, IMO).

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI error messages

[Eli Zaretskii]

> Date: Fri, 10 Feb 2006 10:26:02 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> On Fri, Feb 10, 2006 at 05:22:31PM +0200, Eli Zaretskii wrote:
> > > I don't think the function name adds much value in user-level error
> > > messages.
> > 
> > MI is not a user-level protocol, it's a machine-level protocol.  What
> > is displayed to the user as a result is another matter.
> 
> These are just the result of calls to error ().  Admittedly, many of
> them are for mistakes that a GUI shouldn't be making - but some can
> easily come from user input, so when you get one, I don't think you've
> got much choice but to display it to the user.

We are miscommunicating: what I meant was that the front end can
display whatever it wants in response to such a message.  In
particular, it can remove the function name.  But that is a separate
matter; what is being discussed is what the front end should expect,
not what it should display to the users.

> > We should either have all or none of the MI messages state the
> > function.  A machine-oriented interface must be consistent, IMO.
> 
> Then they'll have to go

Fine with me.

Re: MI error messages

[Mark Kettenis]

> X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on 
> 	elgar.sibelius.xs4all.nl
> X-Spam-Level: 
> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=no 
> 	version=3.1.0
> X-From_: gdb-return-24221-m.m.kettenis=alumnus.utwente.nl@sourceware.org  Fri Feb 10 16:23:07 2006
> Date: Fri, 10 Feb 2006 17:22:31 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Reply-to: Eli Zaretskii <eliz@gnu.org>
> X-IsSubscribed: yes
> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
> Sender: gdb-owner@sourceware.org
> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information.
> X-UTwente-MailScanner: Found to be clean
> X-MailScanner-From: gdb-return-24221-m.m.kettenis=alumnus.utwente.nl@sourceware.org
> 
> > Date: Fri, 10 Feb 2006 08:47:01 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > On Fri, Feb 10, 2006 at 01:54:08PM +0200, Eli Zaretskii wrote:
> > > > From:  Vladimir Prus <ghost@cs.msu.su>
> > > > Date:  Fri, 10 Feb 2006 14:35:08 +0300
> > > > 
> > > > 1. Is it guaranteed that all MI error message start with function name and a
> > > > semicolon?
> > > 
> > > I see a small number of error messages that don't, but those are
> > > probably bugs that need to be fixed.
> > 
> > Really?  Why?
> 
> For consistency.

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?

Mark

Re: MI error messages

[Jim Blandy]

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.

Re: MI error messages

[Nick Roberts]

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));

MI error messages

[Nick Roberts]

 > 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 think these
shouldn't also get reported on the log/error stream (prefixed with &).  In the
end we didn't resolve the issue and nothing was changed.

 > So, could somebody tell:
 > 
 > 1. Is it guaranteed that all MI error message start with function name and a
 > semicolon?

Not currently, look at the sources.

 > 2. If not, is there any regexp that can be used to remove the function name,
 > that's guaranteed to work for all current and future MI error messages.
 > Removing anything before first semicolon is risky -- error message can
 > contain ':' for other reasons.

If you are going to rely on any syntax, you need to check current messages
and document any rules for future reference.

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

Nick

Re: MI error messages

[Vladimir Prus]

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

Re: MI error messages

[Nick Roberts]

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

If you're trying to give one variable the value of another then I guess you're
right.  I've only set variables to prescribed values while debugging.  

However, I still maintain that 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.  Its just that your example, perhaps, belongs to the
former and not the latter.

Nick