From: Vladimir Prus <ghost@cs.msu.su>
To: gdb-patches@sources.redhat.com
Subject: Re: cleanup mi error message handling
Date: Sat, 29 Mar 2008 14:22:00 -0000 [thread overview]
Message-ID: <fsljad$h6f$1@ger.gmane.org> (raw)
In-Reply-To: <20080325021214.GA31594@caradoc.them.org>
Daniel Jacobowitz wrote:
> On Tue, Mar 25, 2008 at 01:28:26PM +1200, Nick Roberts wrote:
>> > > Just as you say if the "frontend wants to display this error to the user
>> > > in the console, it can do so anyway" isn't it equally true that if it
>> > > doesn't want to display this error, it can choose not to so?
>> >
>> > Yes, but unlike a formatted MI response, the front end doesn't know
>> > what a random bit of ~"output" is. It might be a notification, like a
>> > new thread, or an error message, or...
>>
>> Errors aren't CONSOLE-STREAM-OUTPUT but LOG-STREAM-OUTPUT and are prefixed
>> with `&' not `~':
>>
>> &"The program is not being run.\n"
>> ^error,msg="The program is not being run."
>> (gdb)
>>
>> =thread-created,id=2
>> ~"[New Thread 0xb7568b90 (LWP 19810)]\n"
>
> Whoops, you're right. Sorry for confusing the issue.
>
> `"&" STRING-OUTPUT'
> The log stream contains debugging messages being produced by GDB's
> internals.
>
> I still think that means we shouldn't be producing them for
> errors.
I agree. What happens now is that on errors, Eclipse shows the error message
in red. Good, however since it does not show the MI commands user will
know what something is wrong, but won't have any clue why. If the point is
just to show to the user that some error has happened, then the ^error is pretty
sufficient. And if we enable logging of MI commands, user can see the
information even if nothing goes to "&" channel.
So I'd agree that removing those error messages is good. I plan to review
the patch in detail next week.
- Volodya
next prev parent reply other threads:[~2008-03-29 14:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-24 18:30 Pedro Alves
2008-03-24 19:08 ` Pedro Alves
2008-03-24 22:04 ` Nick Roberts
2008-03-24 22:39 ` Daniel Jacobowitz
2008-03-24 23:37 ` Nick Roberts
2008-03-25 1:00 ` Daniel Jacobowitz
2008-03-25 1:29 ` Nick Roberts
2008-03-25 2:12 ` Daniel Jacobowitz
2008-03-29 14:22 ` Vladimir Prus [this message]
2008-03-30 5:13 ` Nick Roberts
2008-03-30 6:06 ` Vladimir Prus
2008-03-31 0:46 ` Nick Roberts
2008-03-31 1:59 ` Daniel Jacobowitz
2008-03-31 2:23 ` Nick Roberts
2008-03-31 5:07 ` Vladimir Prus
2008-03-31 6:36 ` Nick Roberts
2008-03-31 7:10 ` Vladimir Prus
2008-03-31 15:17 ` Pedro Alves
2008-03-31 11:24 ` Pedro Alves
2008-04-01 2:00 ` Pedro Alves
2008-04-01 0:18 ` Pedro Alves
2008-04-01 13:17 ` Nick Roberts
2008-04-01 3:28 ` Nick Roberts
2008-03-25 3:52 ` Pedro Alves
2008-04-04 13:33 ` Vladimir Prus
2008-04-04 23:08 ` Pedro Alves
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='fsljad$h6f$1@ger.gmane.org' \
--to=ghost@cs.msu.su \
--cc=gdb-patches@sources.redhat.com \
/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