FATAL log level..?

[Talkless]

Qt has qFatal that prints and aborts application.

I wonder how spdlog users implement this, do they all create their own helper? Maybe worth having something like that in spdlog? Or ability (or custom handler of sorts?) to configure so that critical will abort?

[tt4g]

In my personal opinion, logging libraries do not need to provide a feature that forces applications to terminate.
Even if a fatal error occurs, some applications must begin the termination process only after releasing resources. For such applications, it is problematic if the application is terminated automatically simply because a fatal error was logged at the FATAL log level.

In addition, spdlog provides asynchronous logging features. If the application crashes immediately after a FATAL log function is called, asynchronous log output is not guaranteed.

[Talkless]

If the application crashes immediately after a FATAL log function is called, asynchronous log output is not guaranteed.

Would spdlog::shutdown(); help before std::abort() ?

[tt4g]

Yes, spdlog::shutdown() flushes the logs as much as possible.

[eyalroz]

In my personal opinion, logging libraries do not need to provide a feature that forces applications to terminate.

Agreed. Separation of concerns.

[Talkless]

In my personal opinion, logging libraries do not need to provide a feature that forces applications to terminate.

IMO it would be helpful utility. For exmaple, Qt also invokes platform-specific _CrtDbgReportW on qFatal():

https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qlogging.cpp?id=9f5a1393b16a1bf336422845bb53e3112d958363#n2156

Separation of concerns.

Too pedantic IMO. We create libraries to be used for productivity, not to appeal ideals.

A lot of devs probably re-implementing their own fatal("message").

[eyalroz]

Too pedantic IMO. We create libraries to be used for productivity, not to appeal ideals.

Separating library concerns enhances productivity better than complecting them. Library developers don't have to write a bunch of code trying to foresee whether or when the application would want them to exercise other kinds of functionality; and application authors would need to keep in mind whether their logging library actions might have unexpected side-effects.

You can always write something like:

template <typename... Ts>
[[noreturn]] void die(Ts&&... args) {
    spdlog::critical(std::forward<Ts>(args)...);
    exit(EXIT_FAILURE);
}

... or whatever. You could even name that spdlog::fatal().

[Talkless]

You can always write something like:

Heh, and you did it incorrectly. You have forgot spdlog::shutdown(). And it should be abort() to avoid calling any static object destructors as app is already in probably in undefined state.

That's the point - lot's of developers have to write same functionality when it could be already implemented in the right way, with extra bells and whistles like in Qt example with _CrtDbgReportW, _CrtDbgBreak() and maybe with latest std::breakpoint().

[eyalroz]

You can always write something like:

Heh, and you did it incorrectly. You have forgot spdlog::shutdown(). And it should be abort() to avoid calling any static object destructors as app is already in probably in undefined state.

POint taken regarding shutdown, but - you're assuming that the app is in an undefined state and the user wants to not call destructors; that is just one of four possibilities: is/isnt in a problematic state, wants/doesn't want to destruct static/global objects. It might be one of the other possibilities. So, implementing a fatal() may avoid my mistake, but it may also do something against the user's expectations.

(Also, one could argue that a critical error may be expected to flush immediately but that's a separate discussion.)

[Talkless]

qt (as already mentioned) has qFatal()
glog has FATAL: https://google.github.io/glog/0.7.1/logging/
abseil has LOG(FATAL): https://abseil.io/docs/cpp/guides/logging
easylogging has configurable aborting: https://github.com/abumq/easyloggingpp/blob/1272515122ce559e77144a8404f419fee0423b81/src/easylogging%2B%2B.cc#L2642

Boost, Poco, log4cplus does not have aborting helper though.

[tt4g]

Whether a logging library (or feature) supports abort depends on its design.
Then, support for it in spdlog is up to the maintainer.

[Talkless]

support for it in spdlog is up to the maintainer.

Of course. I've just provided arguments and other examples.