[Development] [Request] Add Info to QDebug

Mon Dec 23 14:06:07 CET 2013

On 23 Dec 2013, at 12:00, development-request at qt-project.org wrote:

> From: Alejandro Exojo <suy at badopi.org>
> Subject: Re: [Development] [Request] Add Info to QDebug
> Date: 22 Dec 2013 19:01:51 GMT+1
> To: development at qt-project.org
> 
> 
> El Saturday 21 December 2013, Kurt Pattyn escribió:
>> Qt currently supports the following ‘severity’ levels for logging: Debug,
>> Warning, Critical, Fatal and System.
>> 
>> I propose to add the following levels: Info and Error, with associated
>> methods qInfo() and qError(). Particularly, the Info severity can be
>> interesting to have applications output log messages that are not
>> warnings, but also not debug messages. Error would fit between Warning and
>> Critical.
> 
> While not a terrible thing to have, I fail to see what's exactly the use case. 
> I think it would even cause some confusion.
> 
> The "info" level doesn't make much sense for a class that outputs to stderr. 
> If you want to inform the user with text, you probably want the standard 
> output, isn't it?

Debug messages are for debugging purposes. These types of messages can be redirected to an attached debugger if wanted.
In a released applications, debug messages are supposed to be suppressed.
However, some applications do want to log informational messages that are not warnings.
Currently, there is no way to do this through the QDebug class. 

> 
> About "error", I don't see when you would use it instead of the other or which 
> advantadge it gives. I see it this way:
> 
> - Debug: almost everything goes there. Since it can grow messy quickly, you 
> have the categories to filter things easily. Is disabled by QT_NO_DEBUG_OUTPUT 
> since users might be spared of those messages.
> 
> - Warning: is a notice that something went wrong, but it might not affect the 
> application. You can disable it with QT_NO_WARNING_OUTPUT since is not that 
> important.
Warnings are not errors, and do not require immediate action; example: file system is 80% full.
They normally indicate that something might go wrong in the future if no action is taken.

Errors are conditions in an application that do not need urgent attention, but should be resolved as soon as possible.
The application keeps working, possibly with reduced functionality or performance.

> - Critical: something serious really happened, so the message can't be 
> disabled. You really want to print something because something critical is 
> happening.
Critical conditions make the application loose essential functionality. The application cannot be used anymore for its intended purpose.

> - Fatal: same as above, but the application even aborts afterwards.
Fatal conditions affect not only the application, but also the surrounding system. The application and possibly the whole system should be shutdown immediately.
A good example is loss of control of an X-ray beam in an X-ray scanner. Even in this situation, just kicking out the application is very often not a good option. It often should start an emergency procedure.

> 
> The Error level would only make sense if for whatever reason you want to 
> follow Unix syslog, but we are not going to get it right at this point IMHO, 
> since syslog has a lot of levels that are just numerical behind the scenes. 
> From syslog(2) manpage:
> 
>       #define KERN_EMERG    "<0>"  /* system is unusable               */
>       #define KERN_ALERT    "<1>"  /* action must be taken immediately */
>       #define KERN_CRIT     "<2>"  /* critical conditions              */
>       #define KERN_ERR      "<3>"  /* error conditions                 */
>       #define KERN_WARNING  "<4>"  /* warning conditions               */
>       #define KERN_NOTICE   "<5>"  /* normal but significant condition */
>       #define KERN_INFO     "<6>"  /* informational                    */
>       #define KERN_DEBUG    "<7>"  /* debug-level messages             */
> 
> That would make necessary to create Alert and Emergency too. That's quite 
> overkill IMHO.

The proposal is not to mimic the syslog events, but at least to have a more fine-grained control over the log messages.
Most logging systems have the info and error severity levels. Here is a small overview together with a potential mapping to qDebug, qInfo, …:

Microsoft (see http://msdn.microsoft.com/en-us/library/ff604025(v=office.14).aspx):
---------------------------------------------------------------------------------------------------------------
Information      => qInfo
Warning           => qWarning
Error	                => qError
Critical Error    => qCritical

No Fatal severity here.

BlackBerry (see http://www.qnx.com/developers/docs/qnxcar2/index.jsp?topic=%2Fcom.qnx.doc.neutrino.utilities%2Ftopic%2Fs%2Fslogger2.html):
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SLOG2_DEBUG2        => qTrace (I know, does not exist)
SLOG2_DEBUG1        => qDebug
SLOG2_INFO              => qInfo
SLOG2_NOTICE         => qWarning
SLOG2_WARNING     => qWarning
SLOG2_ERROR         => qError
SLOG2_CRITICAL      => qCritical
SLOG2_SHUTDOWN => qFatal

OSX/IOS (ASL: see https://developer.apple.com/library/mac/documentation/macosx/conceptual/bpsystemstartup/chapters/LoggingErrorsAndWarnings.html):
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Debug          => qDebug
Info               => qInfo
Notice           => qInfo
Warning        => qWarning
Error             => qError
Critical          => qCritical
Alert        	     => qCritical
Emergency   => qFatal

The Linux syslog has the same severities as ASL.

Android (see http://developer.android.com/reference/java/util/logging/Level.html):
-----------------------------------------------------------------------------------------------------------
Level.FINEST          => qTrace (I know, does not exist)
Level.FINER            => qDebug
Level.FINE               => qDebug
Level.INFO               => qInfo
Level.WARNING      => qWarning & qError
Level.SEVERE         => qCritical

Android does not provide an error level; both qWarning and qError would translate into Level.WARNING

I have already submitted an implementation of these extra levels into the dev branch: https://codereview.qt-project.org/#change,74338

Feel free to review...