Clarification on how to use Qt's debugging techniques

[hackerNovitiate]

I've just read http://doc.trolltech.com/4.6/debug.html and want to make sure that I understand it properly.

Is it correct to say that qDebug(), qWarning() and the debugging macros are used for debugging during development, and can be compiled to nothing for a release build... but qCritical() and qFatal() are used for reporting runtime errors during normal use (e.g. lost connection to a remote server)?

[tbscope]

I've just read http://doc.trolltech.com/4.6/debug.html and want to make sure that I understand it properly.

Is it correct to say that qDebug(), qWarning() and the debugging macros are used for debugging during development, and can be compiled to nothing for a release build...

Yes

but qCritical() and qFatal() are used for reporting runtime errors during normal use (e.g. lost connection to a remote server)?

Never, ever, not once in your lifetime, use those or asserts in production software! I do horrible things to you if I use a program of you and it crashes without any reason or it doesn't report the errors correctly. A lost connection is NO reason to create those two debug messages or even an assert. You should handle those errors gracefully.

Only use runtime debugging when developing your software. You can build your program to activate runtime debugging in a release build to create a log or something else so you can debug on the target machine too by setting a variable or clicking a checkbox. But don't use debugging already activated in production software.

[hackerNovitiate]

Never, ever, not once in your lifetime, use those or asserts in production software! I do horrible things to you if I use a program of you and it crashes without any reason or it doesn't report the errors correctly.

Urgency noted! I found out later that qFatal() forces an abort and a core dump. At first I thought qCritcal() and qFatal() were for release-build debugging because they don't get compiled away, but now I gathered that the QDebug family is for developmental debugging only.

You can build your program to activate runtime debugging in a release build to create a log or something else so you can debug on the target machine too by setting a variable or clicking a checkbox.

Hmm... so if debugging were enabled on a release build, should I use a generic QTextStream to write to a file, or is there something else that is designed for release-build debugging?

[tbscope]

You can redirect qDebug() output to a file.
QDebug::QDebug ( QIODevice * device )

This means that you can construct a different debug stream depending on the type of executable. When in debug mode write to stderr/stdout or console and when in release mode, write to a file for example.

[squidge]

qCritcal() and qFatal() and for exactly what they say. If some critical occurs in your app and you can't recover from it graciously (for example, a memory allocation fails and trying to create a dialog to inform the user also fails, or you notice memory corruption and can no longer depend on the integration of your application), then you can use them to shutdown your app before anything gets worse. For most errors (such as lost connection to a server) you should just inform the user and recover.

[hackerNovitiate]

Thanks, tbscopde and fatjuicymole. It's all much clearer now.

Part of my confusion was because I got QT_NO_DEBUG and QT_NO_DEBUG_OUTPUT mixed up. The former is defined in Qt Creator's makefile.release, so I thought a release build automatically suppress debug (and warning) messages.