Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

enable assertions in production code



  • How to enable assertions in production code?

    Q_ASSERT is ignored if QT_NO_DEBUG is defined [1]. This is analogous to assert from <cassert>, which is ignored if NDEBUG is defined.

    However, this analogy is flawed because it is perfectly legitimate [2] to compile production code without NDEBUG, whereas, if I understand correctly, it is no good idea to configure Qt Release builds with undefined QT_NO_DEBUG.

    I want assertions to detect improbable bugs. If triggered, they shall terminate my application, and display an error message that contains source file and line number. Ideally through qFatal.

    Solutions:

    1. undefine QT_NO_DEBUG - which problems would that entail?
    2. write an ASSERT macro of my own - how would it get source file name and line number?
    3. use assert from <cassert> - again, how would it get source file name and line number, and how would it call qFatal?
    4. other ideas?

    [1] https://doc.qt.io/qt-5/qtglobal.html#Q_ASSERT
    [2] man 3 assert



  • Well, since you're doing something that is generally shunned in release code, yes, you would need to implement your own macros or functions to do this. getting source file and line number information is through compiler recognized macros that I don't remember off the top of my head.

    __source__ ???
    __line__ ???

    customers don't like error message and crash scenarios...it lowers their confidence in the product.



  • @Kent-Dorfman said in enable assertions in production code:

    customers don't like error message and crash scenarios...it lowers their confidence in the product.

    Well, yes, but by the time the code is about to assert at runtime it's a bit late, isn't it...! You would advocate not outputting a message and just letting the code continue in whatever random state it's in, and perhaps crashing later anyway, first having wiped their data? :) Perhaps this is a conversation for elsewhere....


Log in to reply