|Anonymous | Login | Signup for a new account||2017-10-17 07:50 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000751||EMStudio||General||public||2012-10-25 14:11||2012-12-28 23:52|
|Target Version||0.0.1||Fixed in Version|
|Summary||0000751: Add Q_ASSERT_X() assertions for slot/signal connections|
ok = QObject::connect( ... );
Q_ASSERT( ok , "freeemscomms", "Connection misconfigured!");
|Steps To Reproduce||Wrongly configure a connection, launch app, experience inexplicable behaviour.|
|Additional Information||Simple and easy to do, and provides a large measure of robustness to the app.|
|Tags||No tags attached.|
|Added Sean to watch this. Please do likewise in the loader.|
|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.|
|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 ?|
|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.|
|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.|
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.
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...
|Ditto this one, sir! :-)|
|Copyright © 2000 - 2011 MantisBT Group|