Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000751EMStudioGeneralpublic2012-10-25 14:112012-12-28 23:52
Assigned Tomalcom2073 
PlatformAllOSAllOS VersionAll
Product Version0.0.1-SNAPSHOT 
Target Version0.0.1Fixed in Version 
Summary0000751: Add Q_ASSERT_X() assertions for slot/signal connections
Description [^]

bool ok;
ok = QObject::connect( ... );
Q_ASSERT( ok , "freeemscomms", "Connection misconfigured!");
Steps To ReproduceWrongly configure a connection, launch app, experience inexplicable behaviour.
Additional InformationSimple and easy to do, and provides a large measure of robustness to the app.
TagsNo tags attached.
Issue TypeImprovement
Attached Files

- Relationships

-  Notes
User avatar (0002366)
Fred (administrator)
2012-10-25 14:11

Added Sean to watch this. Please do likewise in the loader.
User avatar (0002379)
malcom2073 (manager)
2012-11-06 18:47

Something to note, Q_ASSERT/Q_ASSERT_X are disabled in release builds, so do not use it for this. An error in signal/slot connection should provide an informative message box for the user to report an issue.
User avatar (0002381)
sean94z (reporter)
2012-11-06 18:49

In your release script you could build it twice, one where the tests exits and if they pass go fwd and build the release bins ? thoughts ?
User avatar (0002382)
Fred (administrator)
2012-11-06 19:00

What is a "release" build? I'm unaware of you having created release scripts as yet. All normal CI builds should use assert-full builds, as should a standard build with make on the CLI. As Sean rightly points out, an actual release script would thoroughly test the app and bail out if any issues were found. Building it twice seems reasonable for this rare event.
User avatar (0002383)
sean94z (reporter)
2012-11-06 19:11

When I said "release" I was referring to "CONFIG +=" directives, like "qtestlib" or "debug". Some *features of qt are only invoked if the CONFIG permits, or so that's how I understand it, as of now.
User avatar (0002384)
malcom2073 (manager)
2012-11-06 20:42

Not sure what you mean Sean, asserts are runtime things, not compile time. There's no way without running the application to know if the assert passes or fails. Q_ASSERT is purely a debugging tool for development use, not an end-user thing.

You are right about the CONFIG parameter. When RELEASE is defined (hence, "release build", asserts are disabled. Building with DEBUG defined, they are enabled (and debugging symbols are built in, and Qt debug libraries are required, etc etc). That's a big nono, since debug libraries are hundreds of megs in size.

Q_ASSERT != void assert(int expr).

I do agree that a form of checking is required, but Q_ASSERT is not the proper way. Nor is assert(), since it in no way helps the end-user file a bug report.
User avatar (0002385)
Fred (administrator)
2012-11-06 20:58

Let me make this perfectly clear: THE END USER SHOULD **NEVER** BE EXPOSED TO THESE ERRORS. They are BUILD time errors, and/or TEST time errors, not distributed.

People building from source should be building with debug libs by default. Obviously your release builds should not, but that's for release, not every tom dick and harry building it from source...
User avatar (0002496)
Fred (administrator)
2012-12-28 23:52

Ditto this one, sir! :-)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker