Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. debug build - continue after Q_ASSERT (no abort)
Forum Updated to NodeBB v4.3 + New Features

debug build - continue after Q_ASSERT (no abort)

Scheduled Pinned Locked Moved Solved General and Desktop
5 Posts 4 Posters 1.1k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    kcris
    wrote on last edited by
    #1

    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

    J.HilkJ JonBJ 2 Replies Last reply
    1
    • K 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

      JonBJ Offline
      JonBJ Offline
      JonB
      wrote on last edited by JonB
      #3

      @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.

      1 Reply Last reply
      1
      • K 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

        J.HilkJ Offline
        J.HilkJ Offline
        J.Hilk
        Moderators
        wrote on last edited by
        #2

        @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.


        Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


        Q: What's that?
        A: It's blue light.
        Q: What does it do?
        A: It turns blue.

        K 1 Reply Last reply
        1
        • K 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

          JonBJ Offline
          JonBJ Offline
          JonB
          wrote on last edited by JonB
          #3

          @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.

          1 Reply Last reply
          1
          • J.HilkJ 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.

            K Offline
            K Offline
            kcris
            wrote on last edited by kcris
            #4

            @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

            1 Reply Last reply
            1
            • KH-219DesignK Offline
              KH-219DesignK Offline
              KH-219Design
              wrote on last edited by
              #5

              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.)

              www.219design.com
              Software | Electrical | Mechanical | Product Design

              1 Reply Last reply
              0

              • Login

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • Users
              • Groups
              • Search
              • Get Qt Extensions
              • Unsolved