All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>,
	qemu-arm@nongnu.org, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt: error_report cleanups
Date: Mon, 09 Nov 2015 19:52:03 +0100	[thread overview]
Message-ID: <878u67atv0.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA8Rh9ts2r-nMGbNm7Y=SpdxL4gv0ch3CBWOHiHTRMeztg@mail.gmail.com> (Peter Maydell's message of "Mon, 9 Nov 2015 15:47:00 +0000")

Peter Maydell <peter.maydell@linaro.org> writes:

> On 9 November 2015 at 10:21, Markus Armbruster <armbru@redhat.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>>> On 9 November 2015 at 07:44, Markus Armbruster <armbru@redhat.com> wrote:
>>>> For consistency, error messages should be a phrase, not a full sentence,
>>>> let alone a paraphraph.
>>>
>>> This is in direct conflict with wanting them to be actually useful
>>> to users :-(
>>
>> I appreciate your drive for useful error messages.  Judging from the
>> error messages we got, it's a rare thing.
>>
>> Let me rephrase.  The error message proper (the thing emitted by
>> error_report()) should be a phrase, and it should be short and to the
>> point.  It can be followed by hints.  Compare:
>>
>>     qemu-system-arm: Unable to determine GIC version supported by
>> host. KVM acceleration is probably not supported.
>>
>> and
>>
>>     qemu-system-arm: Unable to determine GIC version supported by host
>>     KVM acceleration is probably not supported
>>
>> I prefer the latter.  The error message proper is short and to the
>> point.  The hint points to the most probable cause.  Sensible line
>> lengths.
>
> I agree that the latter is preferable; I had been under the
> impression that we weren't allowed to use newlines in error
> messages, though...

error_report()'s contract:

/*
 * Print an error message to current monitor if we have one, else to stderr.
 * Format arguments like sprintf().  The result should not contain
 * newlines.
 * Prepend the current location and append a newline.
 * It's wrong to call this in a QMP monitor.  Use error_setg() there.
 */

If you want to print additional information, that's totally fine!  Use
error-printf().

>> By the way, the error.h API supports this message + hints convention
>> since commit 50b7b00.
>
> Thanks, I had missed this useful improvement to the API.
> How does it work in cases like this where we don't have
> an Error* to fill in?

You do what error_report_err() would do had you had an Error *err to
fill in:

void error_report_err(Error *err)
{
    error_report("%s", error_get_pretty(err));
    if (err->hint) {
        error_printf_unless_qmp("%s\n", err->hint->str);
    }
    error_free(err);
}

In other words, you print the error message proper with error_report(),
and the additional information with error_printf().

error_report_err() uses error_printf_unless_qmp() instead because it
wants to tolerate misuse in QMP context.  It isn't an assertion failure
error mostly for historical reasons.

  reply	other threads:[~2015-11-09 18:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-07 15:25 [Qemu-devel] [PATCH] hw/arm/virt: error_report cleanups Andrew Jones
2015-11-07 16:56 ` Peter Maydell
2015-11-09  7:44   ` Markus Armbruster
2015-11-09 10:01     ` Peter Maydell
2015-11-09 10:21       ` Markus Armbruster
2015-11-09 15:47         ` Peter Maydell
2015-11-09 18:52           ` Markus Armbruster [this message]
2015-11-10  9:31             ` Peter Maydell
2015-11-10  9:39               ` Markus Armbruster
2015-11-10 11:55                 ` Peter Maydell
2015-11-10 13:02                   ` Andrew Jones

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=878u67atv0.fsf@blackfin.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=drjones@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.