debug build - continue after Q_ASSERT (no abort)

[kcris]

Hi,

Is there a way to keep the Q_ASSERT in a debug build but without abort() ing the app when such an assert is hit?

Something like: ok, I see the error, now let's move on

Thanks

[JonB]

@kcris
There are a couple of ways. Partly depends on whether you have already written these Q_ASSERTs or are writing them now.

Easiest is probably to change to

if (!condition)
    qWarning("Message");    // or qWarning() << "Message";

You can always write a Q_WARNING() macro for this along the lines of the Q_ASSERT one.

If you are stuck with using Q_ASSERT you have a couple of choices:

• Look at QtMessageHandler qInstallMessageHandler(QtMessageHandler handler), install your own, and change what it does in "fatal" case to not abort (see https://doc.qt.io/qt-5/qtglobal.html#qFatal).

• Redefine Q_ASSERT macro for your desired behaviour.

• IIRC, under some OSes at least, assert calls abort, and they allow you to redefine that that abort() actually does.

Really code should not have been written to use Q_ASSERT() where it would be safe to continue anyway. Assertions are for non-recoverable error conditions.

[J.Hilk]

@kcris said in debug build - continue after Q_ASSERT (no abort):

Hi,

Is there a way to keep the Q_ASSERT in a debug build but without abort() ing the app when such an assert is hit?

Something like: ok, I see the error, now let's move on

Thanks

Generally, no. The macro is designed to capture programming errors, not user or run-time errors, since it is generally disabled after a program exits its debugging phase

That said, Microsoft does its special soup again. So switch to MSVC and your asserts will behave as you describe it.

[JonB]

@kcris
There are a couple of ways. Partly depends on whether you have already written these Q_ASSERTs or are writing them now.

Easiest is probably to change to

if (!condition)
    qWarning("Message");    // or qWarning() << "Message";

You can always write a Q_WARNING() macro for this along the lines of the Q_ASSERT one.

If you are stuck with using Q_ASSERT you have a couple of choices:

• Look at QtMessageHandler qInstallMessageHandler(QtMessageHandler handler), install your own, and change what it does in "fatal" case to not abort (see https://doc.qt.io/qt-5/qtglobal.html#qFatal).

• Redefine Q_ASSERT macro for your desired behaviour.

• IIRC, under some OSes at least, assert calls abort, and they allow you to redefine that that abort() actually does.

Really code should not have been written to use Q_ASSERT() where it would be safe to continue anyway. Assertions are for non-recoverable error conditions.

[kcris]

@J-Hilk
thanks.
Obviously I will not change the compiler because of the Q_ASSERT though.
Microsoft-ish soup or not, if somebody finds it useful, if there is a "market" for that, there is a reason...
I was just wondering if I missed some #define that might help

@JonB
nice ideas, both helpful. Thanks a lot

ps:
I ended up reinventing the wheel
which is what I did not want and hoped qt already provides in a portable way
I rolled my own QWARNING which does both a qWarning and a debug-break

[KH-219Design]

I, too, have reinvented this wheel.

I was "spoiled rotten" (on this axis, anyway) by using wxWidgets, which does imbue its assert macro with an optional "assert-then-continue" feature.

Here you can find my cobbled-together variation on this theme, which works on Linux and Windows. (it also worked on Mac a while back, but I haven't tested recently, and MacOSX has been changing at a fast pace.)