On 3 May 2014 12:28, Kurt Pattyn <[email protected]> wrote: > Recently I had to remove qWarning statements from a submit (for very > plausible reasons), but a quick search through qtbase revealed a lot of > qWarning statements.
> So are there any rules of thumb? Please also cf. the other thread about using categorized logging from within Qt. It's never good to use qDebug unconditionally, as that's useless information for the users. qWarning, qCritical, qFatal are fine to indicate a major problem, usually originating from user code or from some specific configuration issue. For instance a failing QObject::connect will print a warning through qWarning. Running a setuid binary will trigger a qFatal. Q_ASSERTs go through qFatal if they fail (but they're compiled out in release mode). qCritical is not really used in Qt. qFatal on its own will crash the program; qWarning / qCritical can be set to do the same by exporting QT_FATAL_WARNINGS=1. In programs we work on we strive to get 0 warnings by keeping that env variable set at all times. About qDebug: usually in Qt source code we had debug statements wrapped in macros: [snip] #ifdef ENGINE_DEBUG qDebug() << "Foo" << foo; #endif [snip] or: [snip] #ifdef ENGINE_DEBUG #define engineDebug qDebug #else #define engineDebug QT_NO_QDEBUG_MACRO #endif engineDebug() << "Foo" << foo; [snip] But for new code we should use categorized logging and its tests. Hope this helps, -- Giuseppe D'Angelo _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
