[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 3/7] qemu.py: use python logging system
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH v6 3/7] qemu.py: use python logging system |
Date: |
Wed, 16 Aug 2017 08:17:11 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Eduardo Habkost <address@hidden> writes:
> On Tue, Aug 15, 2017 at 10:10:12AM +0200, Markus Armbruster wrote:
>> Please spell "Python" with a capital "P" (it's a proper name).
>>
>> Amador Pahim <address@hidden> writes:
>>
>> > Let's provide extra control and flexibility by using python logging
>> > system instead of print and/or sys.std*.write().
>> >
>> > Signed-off-by: Amador Pahim <address@hidden>
>>
>> How exactly does this change error messages?
>>
>> Is logging the right tool to report errors to the human user? I'm
>> asking because logging and error reporting are generally separate
>> things. Example: a program runs into a recoverable error. It logs the
>> error, but does not report it.
>>
>> Is reporting errors to stderr the right thing to do for library class
>> QEMUMachine? I doubt it. Libraries throw exceptions and let their
>> users decide how to handle them.
>
> I believe the "qemu received signal" event is supposed to be
> logged, not necessarily reported. Callers can then choose where
> the log messages should go (scripts could choose to send them
> directly to stderr if verbose or debugging mode is enabled). We
> don't even need an exception for it: we can let callers check
> exitcode() and decide what to do about the QEMU exit code.
Makes sense.
> The send_fd_scm() messages, on the other hand, could become
> exceptions, and don't need the logging system at all.
I think we all agree that printing to stderr is not a good idea for this
library class. Instead of a blanket conversion to logging without
further explanation, I'd like to see cleanup with rationale such as
yours.