On 23 Dec 2013, at 14:42, Thiago Macieira <[email protected]> wrote: >> 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. > I don't see the difference between fatal and critical when looking at a > single > application. If the application can't continue, it's fatal for the > application: it's dead. We use qFatal to log situations that terminate the > application.
qFatal has the unfortunate side effect that it ties application termination (quit now) to logging once. An error may well be critical without that meaning that printing the error should cause immediate harakiri. I stick by qFatal being for programmers only, as an alternative to assert, but which triggers in release also. Criticial log level is nice if you want to first print this, then that, then foo, then bar, then cleanup, then quit. FTR, I’m completely -1 for touching QDebug and friends, and +1 for adding a proper logging framework. QDebug, qWarning, qCritical and qFatal are for programmers, not administrators who want app log output for system maintenance. In our app environment, we have (as many else!) added our own Log<Info>() << “bar”, which formats the log output according to our system-wide standard. That makes the logs parseable to all our internal tools. We also override Qt’s debug handlers to ensure that any use of qDebug, warning, critical or fatal ends up properly formatted. I.e. the the debug handler uses our Log thing. Andreas _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
